KR20020022670A - Loop access system with graphical user interface - Google Patents

Abstract

The local access system includes various replaceable resource modules under the control of the regulating unit via a common bus. The system provides a flexible interface to various network communication services such as narrowband POTS, BRI, DDS, Ethernet and SDSL services and wideband DSI and protocols such as ATM, frame repeater, and IP. A management system is provided that allows the user to utilize, configure, and test the system.

Description

LOOP ACCESS SYSTEM WITH GRAPHICAL USER INTERFACE}

There is a need for flexible local access systems to demarcate a wide range of network communication services in central office, remote location and customer premise applications. Local access systems provide an interface between network transmission facilities, switching systems, and custom premise equipment. For example, narrowband and T1, ATM, and frame repeater services, such as legacy telephone service (POTS), basic rate converged telecommunications network (BRIS), and symmetric digital subscriber line (SDSL) services, must all be accessed, which is usually It requires two separate and unique access devices.

In addition, because of the complexity of such access systems, a user interface is required that allows administrators / users to utilize, configure, and test the system.

1 is a block diagram illustrating how a local access system (LAS) can be connected to various network resources.

2 is a block diagram of a LAS configured for universal metallic access.

3 is a block diagram of a LAS configured for point-to-point access.

4 is a block diagram of an LAS configured with STAR connections.

5 is a block diagram of a LAS configured for ADD / DROP connections.

6 is a functional block diagram of a LAS in accordance with the present invention.

7 is a block diagram of a management unit SM according to the invention.

8 is a block diagram of a 4POTS resource module (RM).

9 is a block diagram of a 2OCUDP resource module.

10 is a block diagram of a 4BRI resource module.

11 is a block diagram of a 2DSXI resource module.

12 is a block diagram of an SDSL resource module.

13 is a timing diagram of an INBAND data bus frame format.

14 illustrates a POTS DSO cross connection.

15 illustrates the effect of trunk processing on cross-connections.

16 illustrates signal channel assignment.

17 illustrates a GUI management system (MS) display.

18 illustrates a ZONE A MS display.

19 is a ZONE A1 display including shelf descriptor and screen level information.

20 is a ZONE B MS display.

21 shows a ZONE C MS display.

Fig. 22 is a diagram of a GUI display showing clock management of the SM configuration.

FIG. 23 illustrates selection for various synchronization options as in FIG. 22. FIG.

24 is a diagram for a GUI display showing an SDSL configuration.

FIG. 25 is a diagram for explaining the configuration of interface characteristics as in FIG. 24; FIG.

FIG. 26 is a diagram showing the configuration of a 4POTS module as in FIG. 25; FIG.

Fig. 27 is a GUI view showing a state change notification to a user.

FIG. 28 is a GUI view illustrating how display options are displayed. FIG.

29 is a GUI shelf display view showing cross linking between modules;

30 is a GUI device display user showing all connections associated with the interface of the device selected for the user.

31 is a GUI interface display view.

32 is a GUI display operation view.

Fig. 33 is a GUI ZONE B SM screen and labeled dialog box view;

Fig. 34 is a GUI ZONE B RM screen and labeled dialog box view;

35 is a GUI shelf screen cross-connection view.

36 is a GUI display showing the operation of a "connected by" button.

FIG. 37 is a diagram of a cross-connected MAP interface screen as in FIG. 36. FIG.

FIG. 38 is a drill file down view of FIG. 37; FIG.

39 is a GUI dialog box view.

FIG. 40 is a dialog box view showing that a connection exists as in FIG. 39; FIG.

Fig. 41 is a GUI administrative view of the shelf screen display.

FIG. 42 is a GUI view in which a resource module is clicked as in FIG. 41; FIG.

43 is a GUI interface adjustment view.

44 is a diagram showing the context in which MS software operates.

45 is a top level flow chart for data flow in the GUI.

46 is a side view of an RM module showing access to a fiber connection.

47 is a schematic block diagram for system clock generation and synchronization.

48 is a timing diagram for a synthesized clock timing relationship.

49 is a schematic block diagram for a recovered clock source item option.

50 is a schematic block diagram of a locally derived clock.

51 is a timing diagram for a locally generated clock derived from the backplane.

52 is a timing diagram for a normal TDM frame cycle.

53 is a timing diagram for a clock handoff frame cycle.

54 is a clock replace and return state diagram.

55 is a schematic block diagram of a bus isolation circuit.

56 is a schematic block diagram of an in-rush current circuit.

57 is a timing diagram illustrating a start request.

58 is a schematic block diagram of the backplane guide pin.

59 is a schematic block diagram of a guide pin receptacle.

60 is a block diagram of a LAS configured for SDSL connection to an integrated access device (IAD).

61 is a block diagram for an LAS configured for backplane extension applications.

62A is a frame format with timeslots for voice and data communication between a 2SDSL resource module and an IAD. 62B is a 2SDSL frame format with timeslots for communicating data only. 62C is a 2SDSL frame format for communicating clear channel data.

FIG. 63 is a block diagram of a LAS configuration illustrating trunk conditioning in a 2SDSL application. FIG.

64 is a block diagram for a two-line SDSL resource module.

FIG. 65 is a block diagram illustrating data, signal, clock and synchronization signal connections in a portion of the two line SDSL resource module of FIG. 64; FIG.

FIG. 66 is a block diagram of an upstream signal portion of the FPGA of FIG. 64; FIG.

FIG. 67 is a block diagram of a signal swizzler portion of the FPGA of FIG. 64; FIG.

FIG. 68 is a block diagram of an embodiment of a shelf-manager unit SMU2. FIG.

69 is a block diagram of an LAS configured with an Ethernet protocol resource module.

70 is a block diagram of WAN encapsulation for an Ethernet frame.

71 is a block diagram of an embodiment for an Ethernet protocol resource module.

The present invention provides a highly flexible Local Access System (LAS) and an apparatus for interfacing various network communication services. In a preferred embodiment, the system includes a plurality of resource modules that interface with commonly deployed network transmission facilities, switching system and customer premise equipment. Each module is monitored and regulated by a management unit called a shelf manager (SM) via a message channel and each resource module communicates with the SM via a message channel during initiation using a communication protocol on a single bus. The resource module (RM) is cross-connected to any other resource module via a message channel to provide full time division multiplexing (TDM) time slot exchange capability. A graphical user interface (GUI) management system for LAS is provided to assist the user in performing several functions such as configuration management, equipment, testing, status tracking and statistical reporting.

Each resource module is included in a universal shelf assembly and each module is "hot swappable", which can be removed and replaced while the LAS is active. The method and apparatus for providing clock and timing synchronization to the LAS is integrated into an SM that serves as the main controller of the system bus. RM has the ability to restore timing synchronization. Modules can be inserted and removed without bringing down the system or causing crosstalk or bit errors in the active telecommunication circuitry.

The above objects, features and effects of the present invention will become apparent from the following more detailed description of the embodiments of the invention as shown in the accompanying drawings, in which like reference numerals designate the same throughout the figures. See section. The drawings need not be scaled or highlighted to illustrate the principles of the invention.

For reference, the following abbreviations are used throughout this specification and will be defined herein.

System consideration

Local Access System (LAS) 14 is a very flexible, carrier-class system capable of terminating a range of network services in both central office, remote location and customer-wide applications. The system is based on a modular shelf assembly 12 that can be mounted with various interchangeable interface plug-in units called resource modules 10. See FIG. 1. These resource modules provide interfaces to commonly deployed network transmission facilities, switching systems, and customer premise devices. By selecting the appropriate resource modules, the system supports a wide range of system configurations, among others, features associated with conventional channel banks, data access multiplexers, Ethernet LAN switches, IPDSLAM and digital loop carrier systems.

The system,

Narrowband (e.g., POTS 19, BRI 17, DDS 15, SDSL 13) and broadband 17 (e.g. DS1) services through a group of plug-in resource modules 10 Support.

High capacity for small footprints supporting more than 90 POTS, 40 directly connected SDSL links, 80 ISDN BRI or 160 Ethernet circuits in a single 3U high shelf assembly.

The structure houses resource modules (transports, protocols, and services).

Provides full timeslot replacement at the DS0 level to efficiently manage circuit movement, change and reconfiguration. Cross-connections may be made between any two termination points, ie between one or more DS0s.

· Enables software control to manage, install and maintain with local and remote access.

Fully comply with applicable standards for deployment in central offices or co-located applications.

Integrate resource module slots that support narrowband or wideband resource modules in a line or drop configuration.

· Can be deployed in various network configurations for applications in central offices, remote locations or customer premises.

Feature a resource module 10 that is " hot swappable " and includes individual power converters for increased reliability.

Supports timing options for internal, external synthesized clock and loop timing.

Shelf 12 may be equipped with various resource modules 10 and materialized via management software downloaded from management unit 21 (also provided on the shelf) to provide various configurations and functions, delivery (trunks) and services (customer). Interfaces) and protocols (ATM, frame delay) are common. This flexibility allows service providers to package and deliver customized services to meet their customer's requirements while using their facilities and switching resources efficiently and at low cost. For example, the system may be a physical device (e.g., campus, multi-story building) based on variables such as services required by each individual customer (e.g., data only, POTS and data, few T1) or It can be easily configured by carrier access options (eg, fiber, wireless, telecommunication dedicated lines).

As will be explained in the next section, the system is based on customer premise such as central station / HUB functions such as DS0 / DS1 cross connection and trim, digital loop carrier (DLC) remote end functions such as integrated switch access, and sum / drop multiplex. It can perform device functions.

This section provides a brief description of four example configurations.

Universal metal access configuration

Point-to-point configuration

Constitution

Sum / drop configuration

Universal metal access configuration

As illustrated in FIGS. 1 and 2, the regional access system 14 preferably has a customer premise through the metal loop 20 via a single shelf 12 or a conventional main distribution frame (MDF) located at the hub of the carrier. It consists of a central station providing services to the conditions 18. In this configuration, the system functions as a channel bank to provide metal access 20 to the DS1 facility 16A of the carrier and to provide a cross-connection to the regional switched switch 16D. 16B), function as the DSLAM for the interoffice facility 16C and the service provider's LAN.

Point-to-point configuration

As shown in FIG. 3, in this point-to-point configuration, a remote location area access system (LAS) 14R provides service through the metal interface 22. Remote LAS can be located in cabinets or other off-site shields or installed in the equipment room in a building. The LAS 14L at the central site provides an interface to the regional switched switch or other device shown. If no voice or data exchange device is present at the central site, the service is trimmed using the cross-connect function of the LAS 14 and the traffic is sent to another location through the interoffice facility. As shown in FIG. 3, the interface between the LAS 14L and the central station device 16 may be DS1 or XDSL depending on the type of interface available to the terminal device 16. For example, voice traffic is delivered to the switch via the integrated T1 interface and the ISDN circuit is routed to the switch as a pre-local unit network terminal (LUNT) U-interface. Similarly, private line and data traffic can be routed through DS1 carrier facility Ethernet or demultiplexed into baseband for local terminals. It is noted that the DS1 interface 25 on the LAS is independent of the transmission type and can be transmitted via the fiber, wireless or metal fixture 26.

Constellation composition

As shown in FIG. 4, LAS 14 may be used in a constellation configuration in which service is delivered to three remote locations A, B, and C via local access facility 26. The central site LAS 14C provides a trimmed DS1 interface 25A for efficient use of switches, multiplexers, and interoffice facilities, and provides easy movement, change, and rearrangement capabilities. In this configuration, the DS1 interface 25 appears on the local access side of the unit, but the LAS 14C may provide a metal baseband interface by requiring an appropriate resource module.

Sum / drop configuration

As shown in Figure 5, the LAS 14 can be applied to sum / drop applications. In this figure, locations A, B and C can be said to represent different floors of high-rise billing or other buildings in a campus environment. . In such a configuration, circuits from several nearby locations are merged and trimmed to enable efficient use of local access transmission facilities.

Physically, as schematically shown in FIG. 6, the LAS 14 consists of one or more shelf assemblies 12, each assembly having a common management or control unit called a shelf management unit (SM) 21. Is mounted. The shelf provides a number of slots for the plug-in resource module 10 and one SM 21.

LAS shelf assembly

Shelf 12 (FIG. 6) is a compact unit sized for reference rack mounting comprising 26 slots, of which 25 of the 26 slots include resource modules and one for including SM 21. will be. The shelf includes a high speed distributed backplane (not shown) capable of supporting up to 1024 DS0 cross-connections. The distributed nature of the shelf allows for connectivity between any circuit in the system. The shelf also includes a control or message channel 30 that enables out-of-band communication from the SM to each module in the system via a one-wire interface during initiation. This channel also serves purposes such as material supply, alarm reporting and performance monitoring.

Connections on the backplane enable -48 V, -48 V return, frame ground, composite clock, and dry alarm contacts.

Shelf management unit 21

SM 21 is the central control unit for all system shelf modules. SM provides all the shelf modules with common logic functions including system timing, alarm reporting, software configuration, and performance monitoring.

The SM monitors each resource module 10 through the message channel 30 and provides an interface to software downloads and remote and local operator access.

Resource Module (10)

The resource module can be plugged into any universal slot in the shelf 12 to provide an interface to various services.

The system provides flexibility to service providers, providing a wide range of configurations in a cost-effective manner while supporting a wide range of customer services. This configuration supports a variety of applications using widely deployed transmission media such as fiber optic cables, metal pairs and wireless systems.

There are three resource modules: service, transport and transport protocol resource modules. Modules related to the service include POTS, DDS and ISDN cards for service proposal. Modules involved in the transmission include T1, xDSL, OC3, etc. for the transport connection. Resource modules related to the transport protocol include GR303, IP, TDM, ATM, FR, and the like. Any resource module can be inserted into any of the 25 card slots for its operation. With SM control, the LAS shelf 12 supports digital cross linking and trimming functions between different resource modules for further optimization of the transmission bandwidth. Multiple shelf operations are supported through intertransmission resource module connections. This architecture allows for smooth and painless migration of multiple service proposals through today's circuit switched networks to future IP networks without physical replacement. This is done by software provision via the message channel and by the IP Shelf's IP additional resource modules of the future. Thus, LAS is scalable horizontally and vertically from two circuits to thousands of circuits.

The total throughput of a single shelf is 130Mbps, which exceeds the capacity of DS3.

As shown in FIG. 6, the resource module 10 in any slot has full access to all 2048 DSO bandwidth available on the backplane to ensure full cross-link capacity. In addition, all units are monitored by the SM and communicate with the SM via the control channel 30. For start and end operations, the disconnection bus 13 enables communication between the SM and each resource module. Each type of resource module 10 provides an external interface 32 for cross-connection to an external device via a fully connected cable (not shown) provided with a shelf 12.

The LAS structure provides a number of unique features, including:

Channels associated with any of the resource modules 10 can be cross-connected to any other module, each channel unit of the module being able to read or write on the backplane TSI / data bus 42 from any time slot It provides full time slot exchange (TSI) capability.

Only one common device module 21 is required per shelf, which eliminates the need for a separate common control shelf and reduces the overall system cost.

The resource module 10 can be inserted into any slot, providing the flexibility that the same shelf can be used in any configuration required to support customer applications.

All modules are formed on a printed circuit board of the same physical size, from four POTS cards to OC-3C transceivers.

Maintenance and alarm

SM provides common maintenance and alarm functions centralized in the system. These features include the following:

• Ability to maintain common device settings and resource module configurations in nonvolatile memory.

The ability to store and perform maintenance commands such as loopback initiated through the operator interface.

A function to detect module insertion or removal.

The ability to detect changes in external subscriber interfaces.

Activation of metal audible and visual alarm contact points used for connection to external alarm systems.

This completes the system overview portion of the specification. Next, various units or modules will be described in more detail with signal and communication buses that interconnect or provide a communication path between the modules.

Shelf Management (SM) Unit 21 (FIG. 7)

SM is the intelligent controller unit of the system. The SM performs all the LAS resource modules 10 with centralization of initialization, error monitoring, system timing and synchronization, alarm reporting, maintenance operations, operator interfacing and software download. Configuration and selection of the SM 21 and the resource module 10 is performed through the use of the operator interface 53 located on the SM screen.

The SM's microprocessor 40 provides static RAM, nonvolatile RAM, and flash memory for program storage and execution. The nonvolatile RAM system stores an operation database containing unit configuration data. Each module 12 is provided with a status indicator operable by each microprocessor of each module.

The message channel 44 is a link in communication with the resource module via the bus 42 and transmits configuration data, performance monitoring data, status condition data, alarm information, maintenance instructions and software program downloading. The message channel also regulates the switching of the reference clock source in the event of a failure of the primary source.

Clock recovery and system clock circuits 46 provide centralized control and distribution of timing synchronization clocks. This circuit derives system timing from an external central station synthesis clock received on an office time adjusted line 48 via the backplane I / O 45. The synthesized clock is 64 kbps and is a bipolar return-to-zero signal with a bipolar violation every eight pulses (Bell Core GR-378 (Ref. 6, incorporated herein by reference). ) And ABSITI.01 (Ref.1). The timing can also be derived from the designed DS1, BR1, SDSL circuits (ie, loop timing for line 47). In any case, circuit 46 provides a mechanism for a smooth transition in case the primary timing source fails. In addition, circuit 46 has an internal oscillator that can be employed to provide synchronization over line 41 in case the main source fails.

The alarm processing circuit 50 provides repeater and supporting logic to alarm contact points that are connected to the external alarm panel via the bus 43 and the backplane 45. Minor (loss of one or more reference sources excluding minimum levels), major (if minor alerts persist for 24 hours or all criteria are lost), and critical alerts (when harsh conditions exist and immediate response is required) And an auditory contact relay set.

The DB9 connector port 52 for the operator interface is located on the SM screen. This port is an asynchronous serial link (ie 19200,8,1, N) that can be accessed using a VT100-type craft access terminal or a PC with appropriate terminal emulation software. This interface, which allows the operator / user to manage system sources, enables the following connections:

A menu-based control screen that allows the operator to monitor, configure and maintain all system components; And

Reporting system to detect autonomous system events. These events consist of alerts and common devices, resources (ie data containing) module devices and terminal points.

Resource module type

Several other types of modules are provided in the LAS, including the following in particular:

1. The quad POTS module 4POTS 60 shown in FIG. 8 is equipped with four independent POTS channels 61.

This module is used for long loop applications of bulk ringing available in an external ringing generator (not shown). In addition to typical voice or modem applications, each 4POTS module 60 may also be used in a service outboard exchange (FX) or other application where the system is used in pair gain or digital loop carrier applications.

4POTS module 60 provides an analog voice service using a known loop initiation signal. The 4POTS module also supports on-hook transmission (OHX) for applications such as meter reading and call group identification. Other supported features include unique ringing and forward call disconnection.

The 4POTS module 60 includes a microprocessor 62 with static RAM and flash memory for program storage and execution.

Message channel 64 is a command and control link used for intermodule communication. The message channel sends configuration data, performance monitoring data, status / conditions, and maintenance commands to and from backplane I / O 66.

The individual channel circuits 61 perform the functions belonging to each of the four POTS channels 1-4. The instantaneous protection circuit 71 protects each 4POTS channel 61 from lightning and power cross high voltage transients on the subscriber line. Codec 76 performs analog-to-digital and digital-to-analog conversion from backplane I / O 66 to data bus 63 and POTS interface 68. SLIC (Subscriber Loop Interface Circuit) 74 (see Ref. 25/26) performs all supervision of the current supply and subscriber lines.

The 4POTS module 60 receives supply information (eg, on-hook transmission, etc.) from an external console workstation via a system operator interface (not shown). The 4POTS supply information is stored in the system and downloaded to the microprocessor 62 whenever a new 4POTS is inserted or a download command is entered. Data rate conversion is performed in unit 75 to match the data rate of the 4POTS module to the data rate of the internal RM data bus 63.

Each 4POTS module 60 and a 2DSXI module 110 (described below with reference to FIG. 11) each include signal extraction and insertion units 65 and 123, which units receive information received from the SM 21. And backplane data buses 63 and 128, respectively, to provide universal means for transmitting signal information between terminal points. Since the two units 65 and 123 are substantially the same, only unit 65 will be described here. Unit 65 collects signal information from multiple terminal points and formats the information described in Table 9 above. It includes an FPGA (not shown) that provides a signal multiplex function and a logic function consisting of a step.

POTS extension

As will be described below, variants of the 4POTS module are included in the LAS group for providing extended voice services.

4POTSR is used to provide voice services in short loop applications and includes an on-board ringing voltage generator, the design of which is strongly based on 4POTS.

4POTST has the same hardware structure as 4POTS, supports ground initiation supervision signals, and allows LAS to work with voice switches that work with the TR08 protocol.

2. Dual OCU Data Port Module (2OCUDP) 90 shown in FIG.

The 2OCUDP 90 is equipped with two independent, 4-wire DDS interfaces 92 with backplane I / O 77. The 2OCUDP 90 is typically used to support network access to the reference DDS and the switched 56 service via the backplane I / O 77.

Each 2OCUDP interface 92 may be configured for reference DDS operation or switched 56 kbps operation at data rates up to 64 kbps.

2OCUDP 90 includes a microprocessor 94 having static RAM and flash memory for program storage and execution. Signal processing block 91 provides loop coding violation handling and storage and performance monitoring.

Message channel 96 is a command and control data link used for intermodule communication. The message channel sends configuration data, performance monitoring data, status / conditions, and maintenance commands to and from backplane I / O 77.

The separate channel circuit 99 performs the functions belonging to each of the two OCU data channels 1 and 2. A sealing current 97 of 47 mA is applied. Transient protection 96 protects 2OCUDP from thunder and power crossover high voltage transients on subscriber lines. The DDS transceiver unit 89 performs all line equalization and data extraction in the receive direction and provides pulse shaping and filtering in the transmit direction. The signal processing circuit 91 provides functions for loop quality monitoring, loopback detection and generation, error correction, zero code compression, signal recovery and call progress monitoring. Data rate conversion for fitting the 2OCUDP interface data rate to the data bus 93 data rate is performed in the unit 87.

For all resource modules, 2OCUDP 90 receives supply information (eg, data rate selection, sealing current, etc.) from an external console workstation (not shown) via the system operator interface. The 2OCUDP supply information is stored in the system and is preferably downloaded from the SM to the microprocessor 94 each time a new 2OCUDP is inserted or a download command is entered.

Each 2OCUDP channel independently reports performance monitoring and threshold-crossing conditions to the SM. Each 2OCUDP channel can implement both latching and non-latching loopback conditions. (These software-controlled tools allow evaluation of data path integration from both central and subscriber sites. For additional information about loopback, see See US Pat. No. 5,553,059, incorporated herein by reference.)

3. Quad Base Speed Interface Module (4BRI) 100 shown in FIG.

4BRI 100 is equipped with four ISDN Basic Rate Interfaces (BRI) 102 using 2B1Q modulation. Each 4BRI interface 102 may provide any channel subset using 1,2 or 3 DS0 channels from the 2B + D service or carrier system, depending on the ISDN service being transmitted. 4BRI 100 is used to provide network access to end users via ISDN services for combined high speed data and voice transmission requests over a single circuit. All supplies and diagnostics are controlled by software via an operator interface (not shown) of the system.

The 4BRI includes a microprocessor 104 having static RAM and flash memory for program storage and execution. The microprocessor 104 provides embedded operational channel (EOC) processing and storage, periodic redundancy check (CRC) generation and verification, and performance monitoring.

Message channel 106 is a command and control data link used for intermodule communication. The message channel sends configuration data, performance monitoring data, status / conditions, and maintenance commands to and from backplane I / O 109.

Each 4BRI channel 102 provides functionality such as an ISDN 'U' interface 105 and a line unit network terminal (LULT (ie, interface to subscriber)) or a line unit line terminal (LUNT (ie, interface to network switch)). to provide. Each 4BRI channel configured with LULT provides a selective closure current from unit 108.

The transient protection circuit 101 protects the 4BRI from thunder and power crossover high voltage transients on the subscriber line. ISDN 'U' transceiver 103 performs all 2B1Q line signal encoding and decoding.

4BRI 100 receives supply information (eg, LUNT / LULT, time slots, etc.) from an external console workstation via a system operator interface (not shown). The 4BRI supply information is stored in the system and downloaded to the microprocessor 104 whenever a new 4BRI is inserted or a download command is entered.

Each 4BRI channel 102 independently reports monitoring and threshold-crossing conditions to the SM. This allows for performance data storage at 4BRI RM and system level. For other modules a speed conversion unit 107 is provided.

4. A dual DS1 cross connect RM (2DSX1; 110) is shown in FIG.

The 2DSX1 RM 110 is equipped with two channels 112 to interface to the DS-1 short-haul line facility. Each interface operates over a range of 655 feet from DSX cross-connection. The 2DSX1 is typically used to support data circuits, voice circuits requiring D4 signals, and drop and insert configurations for circuit trim.

As for other modules, the 2DSX1 module 110 includes a microprocessor 114 having static RAM and flash memory for program storage and execution. The microprocessor provides ESF facility data link processing and storage, periodic redundancy check (CRC) generation, verification and performance monitoring.

Message channel 116 is a command and control data link used for intermodule communication. The message channel transmits configuration data, performance monitoring data, status condition data, and maintenance commands to and from the backplane I / O interface 115.

The clock recovery circuit 118 maintains clock synchronization of the 2DSX1 module. In a central station timed system, this circuit receives a clock input from the system via bus 117. In a loop timing situation, synchronization of the system occurs from the operator defined DS-1 interface. The recovered clock signal is routed through the bus 119 to the system for regulation and backplane distribution to all other DS-1 links.

Individual channel circuit 112 performs the functions belonging to each of the two 2DSX1 lines. Line transceiver 120 provides an interface to a DS-1 pair. Line coding (e.g., AMI and B8ZS) is induced to consist of a data stream. The transient protection circuit 122 protects 2DSX1 from thunder and cross high voltage power transients on the subscriber line. Framer 124 provides a frame that formats and signals a pulse for insertion into a data stream. Data rate conversion for fitting the DS-1 data rate to the data bus 128 is performed in the unit 126.

Each 2DSX1 interface independently reports performance monitoring and threshold-crossing conditions to the system. This enables performance data storage at 2DSX1 and system level. Each 2DSX1 link can execute a loopback initiated by the operator. This allows an assessment of data path integrity from central and subscriber sites. Network initiated extended superframe (ESF) lines and loads are also supported.

An alternative embodiment of 2DSX1, called 2T1 and 2T1t, provides all of the above (DSx1) functionality while adding the ability to support long stop (distance) connectivity along with the additional functionality of the Channel Service Unit (CSU). 2T1 Rms provides a signal level that allows the LAS to interface directly with the CSU on the T1 side of the repeater.

Other variations to this RM provide the signal type (eg, D4, TR-08) and format (SF, ESF).

5. Symmetric digital subscriber line module (SDSL) 130 shown in FIG.

The SDSL module 130 is a high speed digital transmission device and operates in full duplex mode over a pair of twisted copper wires using 2B1Q modulation. SDSL is typically used to provide network access to end users whose data transfer needs exceed 56/64 kbps service but do not require full T1. The SDSL module communicates remotely with SDSL or SDSL / FRAD customer premise units.

The SDSL module uses a microprocessor 132 with static RAM and flash memory for program storage and execution. The microprocessor provides EOC message processing and storage, periodic redundancy check (CRC) generation, verification and performance monitoring.

Message channel 134 is a command and control data link used for intermodule communication. The message channel sends configuration data, performance monitoring data, status condition data and maintenance commands to and from backplane I / O 140.

System check recovery circuitry 136 restores synchronization for data bus operation.

The channel circuit 137 performs functions belonging to the SDSL line interface. Sealing current 131 is available as a supply option. The transient protection circuit 133 protects the SDSL from thunder and cross high voltage power transients on the subscriber line. The SDSL transceiver 135 performs all 2B1Q line signal encoding and decoding as required. Data rate conversion for fitting the SDSL data rate to the data rate of the data bus 138 is performed in the unit 139.

The SDSL receives supply information from an external console workstation through the system operator interface. SDSL feed information is stored in the system and downloaded whenever a new SDSL is inserted or a download command is entered.

Backplane Data Bus

The LAS preferably consists of 16 synchronous time division multiplexing (TDM) serial data lines (SD0 to SD15), each serial data line having 8.192 Mbps or 128 digital signal level 0 (DS0) for a total of 131 Mbps or 2048 DS0 LAS bandwidth. ). The entire duplex channel consists of two DS0 time slots.

Each RM channel unit has the ability to write or read in any time slot on the backplane. This provides full time slot exchange (TSI) capability. The channel unit has access to a total of 16.384 Mbps to 256 DS0. The channel unit also has the ability to group multiple DS0s into hyperchannels.

The data lines are synchronized as shown in FIG. SCLK and FSYNC pulses are used for this purpose. Data is shifted onto the bus on the rising edge of the SCLK pulse. The data is shifted off on the bus after or on the falling edge of the SCLK pulse. The time slot counter is reset during the FSYNC pulse and the time slot counter is incremented or reset on the rising edge of the SCLK pulse. "Frame" is defined as 125 ms. Bit 1 of the time slot is transmitted first and is designated as a sign bit for the PCM data, i.

The following describes the protocols and messages used to communicate between external NMs (network managers) (not shown), SM 21 (shelf managers), and RMs 10 (resource modules) via a message channel. These messages are used to convey information such as configuration, performance, status, events, alerts and software. This information transfer is bidirectional. Any NM, SM or RM may initiate a message.

All intrashelf communication is done through the message channel. Inter-node communication will use different communication vehicles. Any module has the ability to talk to any other module. Typically, communication will be between NM and SM or SM and RM. RM interworking between RMs is rare.

The message can be initiated by any module in the shelf. The RM will issue a message to report an event or request a service. The SM will typically send a message to provide information or a request to perform some action. NM, SM and RM are not limited to this particular scenario in any way.

All intermodule communications are defined by the messages described below. Each message includes a header section and a data section. The header section contains common fields for all message types and subtypes. All message types must be supported by all RMs, SMs and NMs. Message subtypes may or may not be supported depending on the particular RM. All subtypes must be supported by all SMs and NMs.

All messages must follow a common template. Each message may consist of 512 bytes of information. The header and data sections are two parts of this template.

There is a 64 byte header at the beginning of each message. The fields in this header are common to all message types. Each field of the header contains a logical value. These values are described in the following sections. 18 bytes are stored in the header for future expansion.

The type / subtype specific data area follows the header. This area can be up to 448 bytes in length.

Message channel

The LAS is provided with a message channel (MC) with a signal rate of 2.048 Mbps to provide communication between the RM channel unit and the SM. The idle condition of the MC is defined as being all ones. If the module writes 1 to the MC but reads 0 at the same time, a bus contention is detected. Bus contention is solved as follows.

1) The module detecting the contention immediately stops the message frame and goes into a high impedance state.

2) The module does not attempt to retransmit until it detects that the MC is in the idle state.

3) Once all frames are sent, the module does not attempt to send another frame until it detects 10 consecutive 1s on the MC.

As shown in the message diagram of Table 1 below, all messages are limited to one common type, whether request-response or voluntary. This standardizes the message justification in software and also makes it easier to add future message types.

Message management

This information allows the message to be recognized, uniquely identified and describes the action to be performed or the information to be conveyed.

Addressing

Occur

Uniquely describes the entity that generates the message. Contains both physical and logical information.

data

This section of the message contains data specific to the message type. Some examples of this include facility provision information and downloaded software.

Table 1

At the beginning of each message is a header. The fields of the header are shared by all message types. These fields are justified by the software for each received message. If the header field contains illogical information, an attempt is made to report the problem to the sender of the message at the sender. If the header is sufficiently damaged, this may not be possible. The message may be discarded by the receiving entity. The message originating entity is required to ensure that the message requesting the response actually gets one. This may be in the form of a receive notification or a time-out. The message generator is responsible for the message until it is eventually notified of its receipt. If the generator determines that it is appropriate, the message may be sent again or other action may be taken.

The message area field of the header is used to characterize the origin and destination control areas of the message.

A copy message (CC) is included in this field. These headquarters messages are generated and transmitted for informational purposes only and are not notified of receipt regardless of message type. These messages may inform some other "unrelated" entities that some message action has taken place. For example, inter-RM interactions may send a copy to the SM for logging and informational purposes.

The following message areas are available.

D_PROC-(0x01)

This area is used for messages remaining in the SM. Interprocess messages will use this area. The value 0x01 is located in the message area field. Message types change and more specifically characterize messages.

D_PROC_CC-(0x81)

This field is used for copy messages remaining in the SM. Interprocess messages will use this area. The value 0x81 is located in the message area field. Message types change and more specifically characterize messages.

D_INTRA-(0x02)

This area is used for messages remaining in the physical shelf. Local SM or RM communication will use this area. The value 0x02 is located in the message area field. Message types change and more specifically characterize messages.

D_INTRA_CC-(0x82)

This area is used for copy messages remaining in the physical shelf. Local SM or RM communication will use this area. The value 0x82 is located in the message area field. Message types change and more specifically characterize messages.

D_INTER-(0x03)

This area is used for messages that originate in the same node but are directed to different physical shelves rather than messages currently residing. The value 0x03 is located in the message area field. Message types change and more specifically characterize messages.

D_INTER_CC-(0x83)

This area is used for copy messages that are within the same node but destined for a different physical shelf than the message in which the originating entity currently resides. The value 0x83 is located in the message area field. Message types change and more specifically characterize messages.

D-NODAL-(0x04)

This area is used for messages destined for other logical nodes than for the originating entity's current residence. The value 0x04 is located in the message area field. Message types change and more specifically characterize messages.

D_NODAL_CC-(0x84)

This area is used for copy messages destined for other logical nodes than the message in which the originating entity currently resides. The value 0x84 is located in the message area field. Message types change and more specifically characterize messages.

D_DOMAIN-(0x05)

This area is used for messages directed to other physical areas than the message in which the originating entity currently resides. The value 0x05 is located in the message area field. Message types change and more specifically characterize messages.

D_DOMAIN_CC-(0x85)

This field is used for copy messages directed to other physical areas than the message in which the originating entity currently resides. The value 0x85 is located in the message area field. Message types change and more specifically characterize messages.

The message type and message subtype fields are used in conjunction to characterize the functionality of the message. The following message types are available.

MSG_A_INFO-(0x10)

This message type is used for messages that require receipt notification. The value 0x10 is located in the message type field. Message subtypes change and more specifically characterize messages. This message type is typically used to notify an event of another entity. For example, an RM wishing to notify the SM of important events will use this message type. The MSG_A_INFO message is one of the most commonly used for all types.

MSG_U_INFO-(0x20)

This message type is used for messages that do not require receipt notification. The value 0x20 is located in the message type field. The message subtype changes and more specifically characterizes the message. This type is used for non-important "information only" messages. Keep-alive messages can be included in this category.

MSG_GET-(0x30)

This message type is used to get information from the message receiver. The value 0x30 is located in the message type field. The message subtype changes. This is used to retrieve the values of the variables controlled by the message receiver. For example, the SM will require a software version of the RM with this message type. MSG_GET messages are always informed of receipt. The receipt notification must contain the required information in the data portion and the status field will reflect the success or failure of the operation. If successful, MSG_GET returns all required variables. In case of failure, none of the required variables are returned.

MSG_SET-(0x40)

This message type is used to convey information to the message receiver. The value 0x40 is located in the message type field. The message subtype changes. This is used to MSG_SET the value of the variable controlled by the message receiver. For example, the SM will send the supply information to be stored in the RM via this type. MSG_SET messages are always notified of receipt. Receipt notification shall reflect the success or failure of the operation via the status field. If successful, MSG_SET configures all required variables. In case of failure, none of the required variables are configured.

MSG_A_ACTION-(0x50)

This message type is used for messages that require receipt notification. The value 0x50 is located in the message type field. Message subtypes change and more specifically characterize messages. This is typically used to require an action to be performed by another entity. For example, an SM that wants to have the RM reset itself will use this message type. The MSG_A_ACTION message is one of the most commonly used for all types.

MSG_ACK-(0x60)

This message type is used to notify the receiving party of the message. The value 0x60 is located in the message type field. The message subtype changes. This type is used to notify receipt of a previous MSG_A_ACTION, MSG_A_INFO, MSG_GET or MSG-SET message. The subtype used will be the same as the received message subtype. The status field is important for this message type and is also required. There is no response to the MSG-ACK message.

Message subtype

S_RM_ILLOG-(0x00)

The S_RM_ILLOG subtype is used by SM and RM only for debugging purposes. Not used under normal circumstances. The responding RM or SM notifies receipt of this subtype. The value 0x00 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses any type and the response uses the MSG_ACK type.

S_RM_ID-(0x01)

The S_RM_ID subtype is used by the SM to request that the RM respond with its identity. The receiving RM notifies the receipt of this subtype with the appropriate identification of the data field. This information will consist of board identification and software version identification. The value 0x01 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSD_GET type and the response uses the MSG-ACK type.

S_RM_DIAG-(0x02)

The S_RM_DIAG subtype is used by the SM to require the RM to perform a self-diagnostic test and respond with the results of the test. The receiving RM notifies the receipt of this subtype with the appropriate diagnostic result of the data field. The value 0x02 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_RM_SW-(0x03)

The S_RM_SW subtype is used by the SM to implement software download to the RM. The RM responds by receiving notification of receipt and storage of the downloaded software segment contained in the message. This software will be included in the data portion of the message. Multiple S_RM_SW messages will be sent until all the software is on the target RM. The value 0x03 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type. Since the downloaded software is included in multiple messages, the segment number field is also used.

S_RM_PROV-(0x04)

The S_RM_PROV subtype is used by the SM to convey supply or configuration information to or from the RM. The RM responds by notifying the receipt and storage of the information segment contained in the message to convey the current value of its supply to the SM. This information will be included in the data portion of the message. Multiple S_RM_PROV messages will be sent until delivery is complete. The value 0x04 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_SET or MSG_GET type, and the response uses the MSG_ACK type. If supply and configuration are included in multiple messages, the segment number field is also used.

S_RM_READY-(0x05)

The S_RM_READY subtype is used by the SM to request the RM to inform the SM that it has begun online operations. The receiving RM completes its own initialization and, when connected to the transmitting facility, informs the reception of this subtype. The value 0x05 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_RM_RTU-(0x06)

The S_RM_RTU subtype is used by the SM or a specialized RM to begin testing for the target RM. The target RM responds by notifying that a message of the requested test operation is being received, completed or in progress. If the progress of the test requires multiple MSG_ACK messages, then the message segment field will also be used. The test result will be included in the data portion of the MSG_ACK message. The value 0x06 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type. The message action field typically specifies the type of test to be performed.

S_RM_RESET-(0x07)

This S_RM_RESET subtype is used by the SM to require the RM to reset or reinitialize itself. The receiving RM erases, removes and resets itself from the bus. The value 0x07 is located in the message subtype field. The request uses the MSG_U_INFO type and no response is expected. The SM eventually expects to receive an S_RM_INSERTED message from the RM.

S_RM_INSERTED-(0x08)

This S_RM_INSERTED subtype is used by the RM to inform the SM that the RM has been inserted or initialized and is ready to be configured. The value 0x08 is located in the message subtype field. The request uses the MSG_U_INFO type and no response is expected. The RM will eventually receive an S_RM_ID request from the SM. The RM will periodically resend the S_RM_INSERTED message until it sees the S_RM_ID message.

S_RM_GO_OFFLINE-(0x09)

This S_RM_GO_OFFLINE subtype is used by the SM to request that the RM enter the offline, non-transmit state. The receiving RM removes itself from the bus and notifies it of this subtype when it is ready to reconnect. The value 0x09 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_RM_SIG_EVENT-(0x0a)

This S_RM_SIG_EVENT subtype is used by the RM to inform the SM that it has detected a reportable event. SM notifies the reception of this subtype when it logs an event. Event information (events, alerts, performance information, etc.) will be included in the data portion of the MSG_A_INFO message. The value 0x0a is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_INFO type and the response uses the MSG_ACK type.

S_RM_INFO-(0x0b)

This S_RM_INFO subtype is used by the RM to inform the SM that it has detected something important to the SM but that it is not necessarily reportable. The SM informs the reception of this subtype when the information is known. The information will be included in the data portion of the MSG_A_INFO or MSG_SET message. The value 0x0b is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_INFO type, and the response uses the MSG_ACK type.

S_SM_ILLOG-(0x0c)

The S_SM_ILLOG subtype is used by SM only for debugging purposes. Not used under normal circumstances. The responding SM notifies receipt of this subtype. The value 0x0c is located in the message subtype field. Message types change and more specifically characterize messages. The request uses any type and the response uses the MSG_ACK type.

S_SM_ID-(0x0d)

The S_SM_ID subtype is used by the master SM to request that another SM respond with its identity. The receiving SM notifies receipt of this subtype with the appropriate identification in the data field. This information will consist of board identification, shelf number, SM unique identifier, and software identification. The value 0x0d is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_GET type and the response uses the MSG_ACK type.

S_SM_DIAG-(0x0e)

The S_SM_DIAG subtype is used by the master SM to require another SM to perform a self-diagnostic test and respond as a result of the test. The receiving SM notifies receipt of this subtype with the appropriate diagnostic result information in the data field. The value 0x0e is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_SM_SW-(0x0f)

The S_SM_SW subtype is used by the master SM to implement software downloads to other SMs. The SM responds by receiving notification of receipt and storage of the downloaded software segment contained in the message. This software will be included in the data portion of the message. Multiple S_SM_SW messages will be sent until all the software is on the target SM. The value 0x0f is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type. Since the downloaded software is included in multiple messages, the segment number field is also used.

S_SM_PROV-(0x10)

The S_SM_PROV subtype is used by the master SM to convey supply and configuration information to or from the SM. The SM responds by notifying the receipt and storage of the information segment contained in the message or conveying the current value of the supply to the master SM. This information will be included in the data portion of the message. Multiple S_SM_PROV messages will be sent until delivery is complete. The value 0x10 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If supply and configuration are included in multiple messages, the segment number field is also used.

S_SM_READY-(0x11)

This S_SM_READY subtype is used by the master SM to request that the other SM report to the master SM that it has started online operations. The receiving SM notifies the reception of this subtype upon completion of its initialization. The value 0x11 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_SM_RTU-(0x12)

The S_SM_RTU subtype is used by the master SM or a specialized RM to begin testing for the target SM. The target SM responds by receiving a message and notifying it of the required test completion or progress. If the progress of the test requires multiple MSG_ACK messages, then the message segment field will also be used. The test result will be included in the data portion of the MSG_ACK message. The value 0x12 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type. The message action field typically specifies the type of test to be performed.

S_SM_RESET-(0x13)

This S_SM_RESET subtype is used by the master SM to require another SM to reset or reinitialize itself. The receiving SM clears and resets itself. The value 0x13 is located in the message subtype field. The request uses the MSG_U_INFO type and no response is expected. The master SM will ultimately expect to receive an S_SM_INSERTED message from the SM.

S_SM_INSERTED-(0x14)

This S_SM_INSERTED subtype is used by the SM to inform the master SM that the SM has just been inserted and initialized and ready to be configured. The value 0x14 is located in the message subtype field. The request uses the MSG_U_INFO type and no response is expected. The SM will ultimately receive an S_SN_ID request from the SM. The SM will resend the S_SM_INSERTED message periodically until it sees the S_SM_ID message.

S_SM_GO_OFFLINE-(0x15)

This S_SM_GO_OFFLINE subtype is used by the master SM to request that the SM go offline. The receiving SM notifies receipt of this subtype if the SM is ready to remove itself from the online operation and reconnect. The value 0x15 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

S_SM_SIG_EVENT-(0x16)

This S_SM_SIG_EVENT subtype is used by the SM to inform the master SM that it has detected a reportable event. The master SM notifies the reception of this subtype when it logs an event. Event information (events, alerts, performance information, etc.) will be included in the data portion of the MSG_A_INFO message. The value 0x16 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_INFO type, and the response uses the MSG_ACK type.

S_SM_INFO-(0x17)

The S_SM_INFO subtype is used by the SM to inform the master SM that the SM has detected something that is important but not necessarily reportable to the SM. When the master SM knows the information, it notifies the reception of this subtype. S_SM_INFO is also used by the master SM to report important information to other SMs. The information will be included in the data portion of the MSG_A_INFO or MSG_SET message. The value 0x17 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_A_INFO and MSG_SET types, and the response uses the MSG_ACK type.

S_SM_STATE-(0x18)

The S_SM_STATE subtype is used by the master SM to convey operational status information to or from the SM. The SM responds by receiving and notifying the reception and storage of the information segment included in the message, or sends the current value of its status information to the master SM. This information will be included in the data portion of the message. Multiple S_SM_STATE messages will be sent until delivery is complete. The value 0x18 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_SET type or the MSG_GET type. If information is included in multiple messages, the segment number field is also used.

S_RM_STATE-(0x19)

The S_RM_STATE subtype is used by the SM to convey operational status information to or from the RM. The RM responds by receiving notification of receipt and storage of the information segment contained in the message, or conveys the current value of its status information to the SM. This information will be included in the data portion of the message. Multiple S_RM_STATE messages will be sent until delivery is complete. The value 0x19 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If information is included in multiple messages, the segment number field is also used.

S_SM_TIMER-(0x20)

The S_SM_TIMER subtype is used by the SM to adjust the timing of message delivery. The message header for the message to be timing will be stored in the data portion of the message along with the timer value. The value 0x20 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_U_INFO type.

S_RM_TIMER-(0x21)

The S_RM_TIMER subtype is used by the RM to adjust the timing of message delivery. The message header for the message to be timing will be stored in the data portion of the message along with the timer value. The value 0x21 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses MSG_U_INFO.

S_NM_TIMER-(0x22)

The S_NM_TIMER subtype is used by the NM to adjust the timing of message delivery. The message header for the message to be timing will be stored in the data portion of the message along with the timing value. The value 0x22 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_U_INFO type.

S_RM_CONN_TS-(0x23)

The S_RM_CONN_TS subtype is used by the SM to convey timeslot cross link information to or from the RM. The RM responds by receiving or notifying the reception and storage of the information segment contained in the message or passes the current value of its timeslot connection information to the SM. This information will be included in the data portion of the message. Multiple S_RM_CONN_TS messages will be sent until delivery is complete. The value 0x23 is located in the message subtype field. Message types change and more specifically characterize messages. The request uses the MSG_SET type or the MSG_GET type and the response uses the MSG_ACK type. If information is included in multiple messages, the segment number field is also used.

Message operation

OP_DUMMY-(0x00)

The OP_DUMMY operation is used by SM and RM as placeholders for message subtypes that do not require an operation type. It is not used under any other circumstances. The responding RM or SM notifies the reception of the OP_DUMMY operation type. The value 0x00 is located in the message operation field. Message subtypes change and more specifically characterize messages. When the request uses the MSG_A_ACTION, MSG_A_INFO, MSG_SET types, the response uses the MSG_ACK type. When a request uses the MSG_U_INFO type, no response is expected.

OP_SW_RM-(0x01)

This OP_SW_RM operation is used by the SM to inform the RM that the message contains the software the RM will store. The RM stores the information contained in the message data field and notifies the reception of this operation type. The downloaded software will be included in the data portion of the MSG_A_ACTION message. The value 0x01 is located in the message operation field. The message subtype is S_RM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_SW_RM_FINAL-(0x02)

This OP_SW_RM_FINAL operation is used by the SM to inform the RM that it has received the last part of the software downloaded. The RM notifies the reception of this operation type if the software has been stored. The last downloaded software part will be included in the data part of the MSG_A_ACTION message. The value 0x02 is included in the message operation field. The message segment field will contain the next sequential number of the sequence generated in the OP_SW_RM message. The message type is S_RM-SW and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_A_ACK type.

OP_TEST_MON_ENABLE_DIG-(0x03)

This OP_TEST_MON_ENABLE_DIG operation is used by the SM to require the RM to prepare itself to be digitally tested in monitor mode. This message is sent early in the test session. The RM notifies the reception of this type of operation when it is ready for additional test operations. It is not included in the data portion of the MSG_A_ACTION message. The value 0x03 is located in the message operation field and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_SPLT_ENABLE_DIG-(0x04)

This OP_TEST_SPLT_ENABLE_DIG operation is used by the SM to require the RM to prepare itself to be digitally tested in split mode. This message is sent early in the testing session. The RM notifies receipt of this type of operation when it is ready for additional testing operations. The data portion of the MSG_A_ACTION message contains the "direction" of the split. The value 0x04 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_MON_ENABLE_MET-(0x05)

This OP_TEST_MON_ENABLE_MET operation is used by the SM to require the RM to prepare itself for metal testing in monitor mode. This message is sent early in the testing session. The RM acknowledges receipt of this type of operation when it is ready for additional test operations. It is not included in the data portion of the MSG_A_ACTION message. The value 0x05 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_SPLT_ENABLE_MET-(0x06)

This OP_TEST_SPLT_ENABLE_MET operation is used by the SM for the RM to prepare itself for metal testing in split mode. This message is sent early in the test session. The RM notifies the reception of this type of operation when it is ready for additional test operations. The data portion of the MSG_A_ACTION message contains the "direction" of the split. The value 0x06 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_MODE_DISABLE-(0x07)

This OP_TEST_MODE_DISABLE operation is used by the SM to require the RM to remove itself from test mode. This message is sent at the end of the test session and is effective for all test enable types. The RM is no longer in test mode, and upon receipt of a regular operation, it receives a notification of this type of operation. It is not included in the data portion of the MSG_A_ACTION message. The value 0x07 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_LOOP-(0x08)

This OP_TEST_LOOP operation is used by the SM to require the RM to perform a loopback. The RM notifies the reception of this type of operation upon completion of the requested test operation. There is nothing included in the data portion of the MSG_A_ACTION message. The value 0x08 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MAG_A_ACTION type and the response uses the MSG_ACK type.

OP_TEST_UNILOOP-(0x09)

This OP_TEST_UNILOOP operation is used by the SM to request RM to release loopback. The RM notifies the reception of this type of operation upon completion of the required test operation. There is nothing included in the data portion of the MSG_A_ACTION message. The value 0x09 is located in the message operation field. The message subtype is S_RM_RTU and more specifically characterizes the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_EVENT_ALARM-(0x0a)

This OP_EVENT_CRITICAL operation is used by the RM to notify the SM of the alert, or by the SM to inform the master SM of the alert. The SM notifies the reception of this operation type upon completion of logging to the reported event. The data portion of the MSG_A_INFO message contains the specific event to be reported. The value 0x0a is located in the message operation field. The message subtype is S_RM_SIG_EVENT (generated by RM) or S_SM_SIG_EVENT (generated by SM) and more specifically characterizes the message. The request uses the MSG_A_INFO type, and the response uses the MSG_ACK type.

OP_EVENT_GEN-(0x0d)

This OP_EVENT_GEN operation is used by the RM to notify the SM of a reportable event or by the SM to inform the master SM. The SM notifies the reception of this operation type upon completion of logging to the reported event. The data portion of the MSG_A_INFO message contains the specific event to be reported. The value 0x0d is located in the message field. The message subtype is S_RM_SIG_EVENT (generated by RM) or S_SM_SIG_EVENT (generated by SM) and more specifically characterizes the message. The request uses the MSG_A_INFO type, and the response uses the MSG_ACK type.

OP_EVENT_PERF-(0x0e)

This OP_EVENT_PERF operation is used by the RM to inform the SM of reportable performance monitoring events or by the SM to inform the master SM. The SM notifies the reception of this operation type upon completion of logging to the reported event. The data portion of the MSG_A_INFO message contains the specific event to be reported. The value 0x0e is located in the message operation field. The message subtype is S_RM_SIG_EVENT (generated by RM) or S_SM_SIG_EVENT (generated by SM) and more specifically characterizes the message. The request uses the MSG_A_INFO type, and the response uses the MSG_ACK type.

OP_SE_RM_SWITCH-(0x0f)

This OP_SE_RM_SWITCH operation is used by the SM to inform the RM that it should start executing the most newly downloaded software. The RM notifies the reception of this type of operation when it is ready to perform the operation. The data portion of the MSG_A_ACTION message contains the version number of the previously downloaded software. The RM will reset itself as a result of receiving this message. The value 0x0f is located in the message operation field. The message type is S_RM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type. The RM will then reset itself and run the current software.

OP_PROV_RM_FACIL-(0x10)

This OP_PROV_RM_FACIL operation is used by the SM to convey facility provision and configuration information to or from the RM. The RM responds by receiving a notification of receipt and storage of the information segment contained in the message, or conveys the current value of its supply to the SM. This facility information will be included in the data portion of the message. Multiple OP_PROV_RM_FACIL messages will be sent until delivery is complete. The value 0x10 is located in the message operation field. The message subtype is S_RM_PROV, more specifically the message. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If facility provisioning and configuration are included in multiple messages, the segment number field is also used.

OP_PROV_RM_SYS-(0x11)

This OP_PROV_RM_SYS operation is used by the SM to convey system parameter configuration information to or from the RM. These may include shelf identification data, timer values to be used, and the like. The RM responds by notifying the receipt of the receipt and storage of the information segment contained in the message and conveying the current value of its supply to the SM. This information will be included in the data portion of the message. Multiple OP_PROV_RM_SYS messages will be sent until delivery is complete. The value 0x11 is located in the message operation field. The message subtype is S_RM_PROV, more specifically the message. The request uses the MSG_SET or MSG_GET type, and the response uses the MSG_ACK type. If supply and configuration are included in multiple messages, the segment number is also used.

OP_SW_SM-(0x12)

This OP_SW_SM operation is used by the master SM to inform the SM that a message contains the software the SM will store. The SM stores the information contained in the message data field and notifies the reception of this operation type. The downloaded software will be included in the data portion of the MSG_A_ACTION message. The value 0x12 is located in the message operation field. The message subtype is S_SM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_SW_SM_FINAL-(0x13)

This OP_SW_SM_FINAL operation is used by the master SM to inform the SM that the last part of the downloaded software has been received. The SM notifies the reception of this type of operation upon receiving the software. The last downloaded software part will be included in the data part of the MSG_A_ACTION message. The value 0x13 is located in the message operation field. The message segment field will contain the next sequential number in the sequence generated in the OP_SW_SM message. The message type is S_SM_SW, and more specifically, the message is characterized. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_SW_SM_SWITCH-(0x14)

This OP_SW_SM_SWITCH operation is used by the master SM to inform the SM that it should start executing the most recently downloaded software. The SM notifies the operation when it is ready to perform the operation. The data portion of the MSG_A_ACTION message contains the version number of the previously downloaded software. The SM will reset itself as a result of receiving this message. The value 0x14 is located in the message operation field. The message type is S_SM_SW, and more specifically, the message is characterized. The request uses the MSG_A_ACTION type and the response uses the MSG_AKC type. The RM will then reset itself and run the current software.

OP_PROV_SM_SYS-(0x15)

This OP_PROV_SM_SYS operation is used by the master SM to convey system parameter configuration information to or from the SM. The information may include shelf identification data, a timer value to be used, and the like. The SM responds by notifying the receipt of the receipt and storage of the information segment contained in the message, or conveying the current value of its supply to the master SM. This information will be included in the data portion of the message. Until the delivery is complete, a number of OP_PROV_SM_SYS messages will be sent. The value 0x15 is located in the message operation field. The message subtype is S_SM_PROV, more specifically the message. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If supply and configuration are included in multiple messages, the segment number field will also be used.

OP_STATE_RM_FACIL-(0x16)

This OP_STATE_RM_FACIL operation is used by the SM to convey facility status information to or from the RM. The RM responds by notifying the reception of the receipt and storage of the information segment contained in the message, or convey the current value for its status to the SM. This facility information will be included in the data portion of the message. Multiple OP_STATE_RM_FACIL messages will be sent until delivery is complete. The value 0x16 is located in the message operation field. The message subtype is S_RM_STATE and the response uses the MSG_ACK type. If supply and configuration are included in multiple messages, the segment number is also used.

OP_STATE_RM_SYS-(0x17)

This OP_STATE_RM_SYS operation is used by the SM to convey RM status information to or from the RM. The RM responds by notifying the reception of the receipt and storage of the information segment contained in the message or conveying the current value of its supply to the SM. This information will be included in the data portion of the message. Multiple OP_STATE_RM_SYS messages will be sent until delivery is complete. The value 0x17 is located in the message operation field. The message subtype is S_RM_STATE, more specifically the message. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If information is included in multiple messages, the segment number is also used.

OP_STATE_SM_SYS-(0x18)

This OP_STATE_SM_SYS operation is used by the master SM to convey status information to or from the SM. The SM responds by notifying the reception of the reception and storage of the information segment contained in the message and conveying the current value of that information to the master SM. This information will be included in the data portion of the message. Multiple OP_STATE_SM_SYS messages will be sent until delivery is complete. The value 0x18 is located in the message operation field. The message subtype is S_SM_STATE, more specifically the message. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If information is included in multiple messages, the segment number field is also used.

OP_SYNC_TICK_SM-(0x19)

This OP_SYNC_TICK_SM operation is used by the master SM to cause time tick resynchronization to occur in the SM. The SM responds by notifying the reception of the information contained in the message and resets its tick synchronization to the value of the information received from the master SM. The information will be included in the data portion of the message. The value 0x19 is located in the message operation field. The message subtype is S_SM_INFO, more specifically the message. The request uses the MSG_SET type and the response uses the MSG_ACK type.

OP_SYNC_TICK_RM-(0x20)

This OP_SYNC_TICK_RM operation is used by the SM to cause time tick resynchronization to occur in the RM. The RM responds by notifying the reception of the information contained in the message and resets its tick synchronization to the value of the information received from the SM. This information will be included in the data portion of the message. The value 0x20 is located in the message operation field. The message subtype is S_RM_INFO, more specifically the message. The request uses the MSG_SET type and the response uses the MSG_ACK type.

OP_SYNC_TIME_SM-(0x21)

This OP_SYNC_TIME_SM operation is used by the master SM to cause time resynchronization to occur in the SM or master SM. The SM responds by notifying the reception of the information contained in the message, and resets the time to the value of the information received from the master SM or NM. This information will be included in the data portion of the message. The value 0x21 is located in the message operation field. The message subtype is S_SM_INFO, more specifically the message. The request uses the MSG_SET type and the response uses the MSG_ACK.

OP_WATCHDOG_RM-(0x22)

This OP_WATCHDOG_RM operation is used by the RM to inform the SM that the RM is still active. This message is sent periodically if no other message activity has occurred recently. The data portion of the MSG_A_INFO message is not used. The value 0x22 is located in the message operation field. The message subtype is S_RM_INFO and more specifically characterizes the message. The request uses the MSG_U_INFO type and no response.

OP_WATCHDOG_SM-(0x23)

This OP_WATCHDOG_SM operation is used by the SM to inform the master SM that the SM is still active. This message is sent periodically if no other message activity has occurred recently. The data portion of the MSG_A_INFO message is not used. The value 0x23 is located in the message operation field. The message subtype is S_SM_INFO and more specifically characterizes the message. The request uses the MSG_U_INFO type and no response.

OP_WATCHDOG_RM-(0x24)

This OP_WATCHDOG_RM operation is used by the NM or master SM to inform the SM that the message contains software for the RM to be stored on the SM storage medium. The SM stores the information contained in the message data field and notifies the reception of this operation type. The software will be included in the data portion of the MSG_A_ACTION message. The value 0x24 is located in the message operation field. The message subtype is S_SM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_WATCHDOG_RM_FINAL-(0x25)

This OP_WATCHDOG_RM_FINAL operation is used by the NM or master SM to inform the SM that the final message containing the RM software to be stored on the SM storage medium has been sent. SM notifies the reception of this operation type. There is nothing included in the data portion of the MSG_A_ACTION message. The value 0x25 is located in the message operation field. The message subtype is S_SM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_SW_SAV_SM-(0x26)

This OP_SW_SAV_SM operation is used by the NM or master SM to inform SM that a message contains software for the SM to be stored on the SM storage medium. The SM stores the information stored in the message data field and notifies it of this operation type. The software will be included in the data portion of the MSG_A_ACTION message. The message subtype is S_SM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_SW_SAV_SM_FINAL-(0x27)

This OP_SW_SAV_SM_FINAL operation is used by the NM or master SM to inform SM that a final message containing the AM software to be stored on the SM storage medium has been sent. SM notifies the reception of this operation type. The data part of the MSG_A_ACTION type is not included. The value 0x27 is located in the message operation field. The message subtype is S_SM_SW, more specifically the message. The request uses the MSG_A_ACTION type and the response uses the MSG_ACK type.

OP_PROV_SAV_RM-(0x28)

This OP_PROV_SAV_RM operation is used by the NM or master SM to convey facility provision and configuration information to or from the SM for the RM to be stored on the SM storage medium. The SM stores the information included in the data field of the MSG_SET message and notifies the reception of this operation type. The data portion will also identify the RM information being queried. Facility provision and configuration information will be included in the data portion of the notification of receipt of the MSG_GET message. The value 0x28 is located in the message operation field. The message subtype is S_SM_PROV, more specifically the message. The request uses the MSG_GET or MSG_SET type, and the response uses the MSG_ACK type.

OP_TS_CONN_SAV_RM-(0x29)

This OP_TS_CONN_SAV_RM operation is used by the NM or master SM to convey timeslot cross-connection information to or from the SM for the RM stored on the SM storage medium. The SM stores the information included in the data field of the MSG_SET message and notifies the reception of this operation type. The data portion will also identify the RM information being queried. The timeslot cross link information will be included in the data portion of the receipt notification of the MSG_GET message. The value 0x29 is located in the message operation field. The message subtype is S_RM_CONN_TS and more specifically characterizes the message. The request uses the MSG_GET or MSG_SET type, and the response uses the MSG_ACK type.

OP_TS_CONN_RM-(0x2a)

This OP_TS_CONN_RM operation is used by the SM to convey timeslot cross-connection information to or from the RM. The RM stores the information included in the data field of the MSG_SET message and notifies the reception of this operation type. The timeslot cross link information will be included in the data portion of the receipt notification of the MSG_GET message. The value 0x2a is located in the message operation field. The message subtype is S_RM_CONN_TS and more specifically characterizes the message. The request uses the MSG_GET or MSG_SET type, and the response uses the MSG_ACK type.

OP_STATE_RM_PM-(0x2b)

This OP_STATE_RM_PM operation is used by the SM to convey performance monitoring status information to or from the RM. The RM responds by notifying the reception of the receipt and storage of the information segment contained in the message or convey the current value of its performance monitoring status to the SM. This performance monitoring information will be included in the data portion of the message. Multiple OP_STATE_RM_PM messages will be sent until delivery is complete. The value 0x2b is located in the message operation field. The message subtype is S_RM_STATE, more specifically the message. The request uses the MSG_SET type or the MSG_GET type, and the response uses the MSG_ACK type. If information is included in multiple messages, the segment number field is also used.

Message Correlation Count

The message correlation number field is used to uniquely identify the message. This can be used for all message types (MSG_GET, MSG_SET, MSG_A_INFO, MSG_U_INFO, MSG_A_ACTION, MSG_ACK). This allows the originating entity to associate the response with the appropriate request message. This is not explicitly required for the MSG_U_INFO message, but is used for consistency. The responding entity will use the correlation number received as the correlation number in the response. This field is required because multiple messages of the same type / subtype are noticeable at any time. For example, if there are three MSG_A_INFO messages with correlation numbers 100,101 and 102, three responses with correlation numbers 100,101 and 102 are expected.

Process ID Occurred

This generating process ID is a number that uniquely identifies the software process that generated the message. This field is always filled in by the message generating process. The responding process uses the value provided in the request message. This is not a process ID assigned by UNIX or another OS. The value 0x00 is not valid for this field.

Response process ID

The response process ID is a number that uniquely identifies the software process that generated the message response, ie MSG_ACK. This field is filled in by the process generating the response message. In the occurrence message, this field is set to the value 0x00 if the sender does not know the id of the responding process. This is not a process ID assigned by UNIX or another OS. The value 0x00 is not valid for this field.

Destination logic node number

The logic node number is part of the destination address of the message. This specifies the id of the group of shelves controlled by the master SM. This will include a nonzero value for inner-node communication. This field should be set to 0x00 for internal shelf messages.

Destination physical shelf number

The physical shelf number is part of the destination address of the message. This specifies the actual physical shelf of the logic node for the operation or information of the message. This field is not always zero.

Destination physical slot number

The physical slot number is part of the destination address of the message. This specifies the actual physical slot of the shelf for the operation or information of the message. This field is not always zero.

Destination physical port number

The physical port number is part of the destination address of the message. This specifies the actual physical port of the RM for the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Destination logic channel number

The logic number is part of the destination address of the message. This specifies the logical channel ID of the RM for the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Destination logic time slot number

The logic timeslot number is part of the destination address of the message. This specifies the RM's logical timeslot ID for the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Logic Node Number Generation

The logic node number is part of the originating address of the message. This specifies the ID of the shelf group controlled by the master SM. This will contain a nonzero value for internal node communication. This field should be set to 0x00 for internal shelf messages.

Generate physical shelf number

The physical shelf number is part of the originating address of the message. This specifies the actual physical shelf of the logic node that requires the operation or information of the message. This field is not always zero.

Generate physical slot number

The physical slot number is part of the originating address of the message. This specifies the actual physical slot of the shelf that requests the operation or information of the message. This field is not always zero.

Generate physical port number

The physical port number is part of the originating address of the message. This specifies the actual physical port of the RM that requires the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Logic channel number occurrence

The logic number is part of the originating address of the message. This specifies the logical channel ID of the RM port requesting the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Logic time slot number occurrence

The logic timeslot number is part of the destination address of the message. This specifies the logic timeslot of the RM requesting the operation or information of the message. If this field is not required for the message, the value 0x00 should be used.

Message segment number

The message segment number is used to indicate a sequence of messages for conveying information that requires more than the maximum number of data bytes available in a message. As an example, software download to the RM will require multiple messages to complete. The message segment number is used to ensure that data is received in the proper order and without loss of segments. This field is set to 0x00 for a single segment message. For multi-segment messages, this field is numbered 0x01. If the message receiving side misses or improperly detects a sequence segment, it may reject any subsequent message segment until the missed segment is received. If the missing segment does not come next, the receiving entity must discard any received segments and must not perform any part of the required action. The sending entity may start a retransmission starting with the missed segment, restart from the beginning, or cancel the entire message.

condition

OK-(0x00)

This state indicates that the requested operation has completed successfully, or is returned to MSG_ACK to indicate that the information has been received and that the information is valid. NON-ACK messages should always set this field to OK.

FAILED-(0x01)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x01 is located in the field. Additional information about the failure may be included in the data field according to the message subtype.

READ_ONLY-(0x02)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x02 is located in the field. This status is typically returned to indicate that an MSG_SET message attempted to modify a read-only variable. Additional information about the failure may be included in the data field according to the message subtype.

BAD_VALUE-(0x03)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x03 is located in the field. This status is returned to indicate that the MSG_SET message attempted to assign an inappropriate value to a variable. Additional information about the failure may be included in the data field according to the message subtype.

NONEXISTENT-(0x04)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x04 is located in the field. This state is returned to indicate that the requested or specified variable does not exist. Additional information about the failure may be included in the data field according to the message subtype.

UNKNOWN_MSG-(0x05)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x05 is located in the field. This state indicates that the received message is illogical and cannot be processed. Additional information about the failure may be included in the data field, depending on the message subtype.

BAD_LENGTH-(0x06)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x06 is located in the field. This state indicates that the number of bytes in the received message is invalid. Additional information about the failure may be included in the data field, depending on the message subtype.

IN_PROGRESS-(0x07)

This state is returned to MSG_ACK to indicate that the requested operation has not yet completed. The value 0x07 is located in the field. This state indicates that the received message is valid. The original message generator will have to register the destination entity later for completion information, otherwise the destination entity returning IN_PROGRESS status will generate an autonomous message. These operations are specific to the message subtype.

BAD_SUBTYPE-(0x08)

This state is returned in MSG_ACK to indicate that the requested operation failed. The value 0x08 is located in the field. This status is returned to indicate that the message subtype is unknown to the receiving entity. All other MSG_ACK message information will be received in MSG_GET, MSG_SET, MSG_A_ACTION or MSG_A_INFO. The illogical subtype of the MSG_U_INFO message will cause the message to be discarded. Any other action taken by the SM or RM depends on the decision of the SM or RM.

BAD_SEGMENT-(0x09)

This state is returned as MSG_ACK to indicate that the requested operation failed. The value 0x09 is located in the field. This status is returned in the opinion of the receiving entity to indicate that the message segment number is illogical, missing, or out of order. All other MSG_ACK message information will be as received in MSG_GET, MSG_SET or MSG_A_INFO. The illogical segment number of the MSG_U_INFO message will cause the message to be discarded. Any other action taken by the SM or RM depends on the decision of the SM or RM.

Message byte count

This field is set to the total length of the message and contains the header and the data portion. This must not exceed the value 512. If there is no data part, the value should be set to 64 to indicate the length of the header.

Message data

Type / subtype-specific data areas follow the header. This area can reach 448 bytes in length. Some types / subtypes do not use this area at this time.

Cross-link processing

Cross-connection establishes logical end-to-end conversion using one or more DS0 per time slot. SM 21 (FIG. 6) controls the establishment and tear down of cross-connections. These connections are assigned by the operator via the operator interface. The assignment of cross-connections establishes a data path (eg, OCUDP to DS1) between two end points on the system shelf.

When the cross-connection establishment begins, the SM

a) it is necessary to justify the cross-connection entry (the equipment and the end points at both ends must be configured) and

b) It is necessary to allocate TDM bus timeslots from those available as shown in Table 2.

Table 2

Cross-connection parameters

Additionally, the transmit and receive timeslot assignments of the backplane structure need to be sent to the resource module where the end points are located. The message channel is used to convey this information. As part of the cross-connection setup, additional parameters related to trunk processing as shown in Table 3 need to be defined.

Table 3

Cross-connection parameter description

The following paragraphs outline the configurable parameters required to fully define a valid cross link.

Number of signal bits (NSIG; NUMBER OF SIGNALING BITS)

NSIG is a parameter used to define the signaling protocol to be used by end points on resource modules at each end of the transmission path. The number of bits specified determines the number of unique states required to support a given signal protocol. Valid settings for NSIG are shown in Table 4. Default settings are based on cross-connected resource module end points. NSIG assumes default values that match the type of cross-connection (see Table 2). When the resource module is 4BRI, xOCUDP or SDSL, the NSIG defaults to 0 (TRSP-Transparent). Table 4 lists the available NSIG options and signaling protocols supported.

Table 4

Number of signal bits

IW (INSERTION WORD)-Insert Word

The insertion word IW specifies an 8-bit word directed to DS0 inserted in the detection of carrier failure. This is usually the idle code of the end point.

Not entering a value in IW implies that the operator does not want the cross-connection to use the default value shown in Table 6.

User-defined six digit code patterns may also be specified.

IW is valid only when the AID (Access ID) for the TO or FROM direction indicates a synchronous DS1 resource module.

Table 6 summarizes the context in which IW is applicable.

Table 5

Insertion word

Table 6

Insertion Word Default Application

Trunk adjustable

The trunk control parameter specifies the signal pattern to be delivered on the DS0 channel that is connected, disconnected and entering the failure condition. This is caused by one end of the cross-connection towards the other end after entering the Carrier Group Alert (CGA) condition. The alert is encoded in a repeating bit pattern using signal bits. Two different patterns are sent. The first (initial) pattern of four bits is transmitted during the first 2.5 seconds of the CGA condition. The second (final) pattern is sent during the duration of the alert condition.

The basic trunk conditioning (TC) pattern is a function of the type of end points, including cross-connections. Only cross-connections with nonzero NSIG can perform this trunk control. See Table 7 below for applicable default values.

Table 7

RPOTS Trunk Condition Signal Bit Default

14 shows a POTS DS0 cross-connection using the following parameters.

FROM AID: 21-2-4

TO AID: 3-2

NSIG: 2

IW: TRB

TC (FROM): 0101 0101

TC (T0): NONE

15 shows trunk processing for cross-connection.

The following describes the signal channel format for transferring information between end points. The default internal system format corresponds to the D4 signal format per AT & T PUB 43801 (Ref. 16). In an embodiment of the invention, in each frame, two separate timeslots (one for Rx and one for Tx) are dedicated to the signals associated with the individual cross-connections.

SM management of signal channels

The signal is used to indicate off-hook / on-hook, ringing, etc. on a voice line. For DS1 signals, these signal indications are often inserted in band via robbed bit signaling (RBS). RBS steals the LSB of every sixth frame for a given voice DSO. This is because a reference to a superframe is as good as possible (2DSX1 RM 110 on board (FIG. 11)). Stolen bits in this band are carried away from the DSX card via a single voice (PCM) DSO, but the signal frame reference is lost and it is impossible to determine where the sixth frame is. The LAS 14 implements a standalone signal channel with its own framing criteria used to carry up to T1 or E1 with signal bit value in real time multiplexed into a single DS0. This signal channel also provides a means for transmitting new framing bits from DS1.

The received signal channel is monitored for signal bits associated with a particular timeslot. Phase bits P ₀ and P ₁ are used to determine signal frame references and valid signal channels. Once the valid signal DS0 has been verified and signal frame criteria have been established, signal bits can be captured. Valid signal channels are repetitive phase patterns, 00,00,00,00,00,00,01,01,01,01,01,01,10,10,10,10,10,10,11,11,11, Can be verified by detecting 11, 11, 11

When the cross link is established, the SM indicates to the end point that the system timeslot will carry Tx and Rx signal information. SM does the following:

Equipment of slot x, end point y, channel z, rx signal on system serial data line i, timeslot k

Equipment of slot x, end point y, channel z, tx signal on system serial data line j, timeslot m

here,

X specifies the slot containing the resource module.

Y identifies the end point on the resource module (eg, DSX-1 on module).

Z identifies the channel on the interface (eg, the end point and channel are the same for POTS).

I, j identifies the serial data line (eg SD0-SD15 of the backplane).

K, m identifies timeslots (eg, timeslots 1-128) corresponding to the channel signal information.

This relationship is shown in FIG.

The SM is responsible for coordinating the relationship of end points, cross-connections and timeslots that carry signal information but do not control it. This simplifies the task of the SM at the expense of system bandwidth.

Signal channel format

As shown above, two timeslots are designated to exercise the signal, one for the transmit direction and one for the receive direction. Each timeslot has the format shown in Table 8.

Table 8

Signal channel byte format

here

P ₁ P ₀ indicates the phase of the signal bit.

S ₁ -S ₄ represent the values of the ABCD signal bits.

F provides a frame allocation signal.

R is reserved.

In one embodiment, S1 is used to carry ABCD signal information of the end point. S ₂ -S ₄ need not be used. However, they should be used whenever the end points between the modules can be grouped together. This will improve overall efficiency in how the system uses the available bandwidth.

Bandwidth usage by system configuration

The expected worst case of bandwidth usage for a system is in a 1/0 / digital cross-connection configuration. In this scenario, the system consists of DSX-1 modules (Figure 11). Each module 110 supports two DSX-1 interfaces, each with 24 channels. System capacity

to be.

In order to support 1200 timeslots for channel cross-connection, 1200 additional timeslots are required for the signal.

Additional signal channel implementation

To support the worst case scenario, the use of a more efficient signal channel format is used for cross-connection to the DS1 end point. This method is required to convey signal information downstream from DS1. The DS0 end point expects the extraction of signal bits using the framing shown in Table 9. This requires the extended use of the signal channel format for signals received in the following manner (i.e. from line to drop side or in this case from DS1 to DS0 side).

Table 9

Extended signal channel format

SF ESF format F ₁ -F ₆ = frame allocation bits

SF format S ₁ -S ₆ = signal framing bits

ESF format M ₁ -M ₁₂ = data link bits

A ₁ -A bit for A ₂₄ channel 1-24

B bit for B ₁ -B ₂₄ channel 1-24

C bit for C ₁ -C ₂₄ channel 1-24

D ₁ -D bit for D ₂₄ channels 1-24

The substantial index 1-24 directly corresponds to the number of cross-connected DS0 timeslots allocated for transmitting voice / data information. This reduces the number of timeslots required to support the worst case scenario by 575 timeslots, which allows full system population.

Signal channels are up to 24 separate signal bit streams (S ₁ to S ₄ repeated 6 times per phase, producing A ₁ -A ₂₄ , B ₁ -B ₂₄ , C ₁ -C _24, and D ₁ -D ₂₄ ). Support. The use of 'spare' bits ('R') adds support for up to 30 signal bit streams. Signal bit reference numbers from 1 to 24 remain the same and additional signal bits occupy consecutive R bit positions for A ₂₅ -A ₃₀ , B ₂₅ -B ₃₀ , C ₂₅ -C ₃₀ and D ₂₅ -D ₃₀ .

Upstream Signal Mapping

The following provides a sequence used to insert signal information upstream to DS-1 via the TS1 TDM bus 42 (Figure 6). For example, assume that type slot 4 on SD1 has been allocated to the transmit signal slot of DS0. Referring to Table 10, it is noted that in the upstream direction, A / B _TX is always written to the first frame bit position.

Table 10

RI = INC reserved for future application.

R = reserved by Bellcore.

The goal is to implement a signal channel format that maximizes the efficiency of the bandwidth used for the signal. All source modules are configured to allow multiple end point signals to enter a single timeslot.

An alternative approach provides multiplexing functionality, aggregation of signals from multiple end points, and formatting as described in Table 9. As now described, the mapping of signals from each end point to the required network format may be implemented internally by the resource module. However, multiplexed signal channels can also be made available on the backplane for external irradiation and verification.

Translation of the signal

Translation of the signal information as carried by the signal channel is defined in AT & T PUB 62310 and is shown in Table 11.

Table 11

Three valid states for any received signal bits '0', '1' and 'Alternating' are defined. The RM logic detects any one of these three states. For each bit (A, B, etc.), the following guidelines are used.

After at least four consecutive ones, one '1' signal bit is declared.

After at least four consecutive zeros, one '0' signal bit is declared.

After at least four consecutive shift bits (ie 0101 or 1010), a 'variable' signal bit is declared.

• All other pattern signal bits are declared 'indeterminate'.

Up to four signal bits can be monitored A, AB or ABCD. It is noted that using the above rules, valid detection can be done within 3 msec. When an input signal stream is declared "invalid", all received signal bits associated with that stream indicate 'undetermined'.

Loop start scenario:

Where A / B _TX is transmitted from RPOTS on the assigned Tx timeslot.

A / B _RX is received by RPOTS via the assigned Rx timeslot.

Graphical user interface

The following describes a graphical user interface (GUI) management system for a local access system (LAS).

The management system MS of the present invention performs various functions for the user. These functions include configuration management, equipment and facility testing, cross-connection mapping, status tracking, event and alarm reporting, and statistical reporting. These features are easy to use and are expected to provide graphical information at a glance. This is accomplished through the use of colors, shapes and sounds to convey and receive information. The user does not have to perform complex operations to operate the MS effectively or to manage the equipment of the LAS. MS is graphical and context sensitive, easy to use and easy to understand.

Microsoft provides a hierarchical methodology for users to operate, maintain and monitor LAS. Matching presentation formats and context-dependent actions simplify management tasks. Tight maintenance of open windows and presentations provides the user with the most clear and concise information format. As an example, changes initiated by all users are shown in red for enhanced visibility before the user applies the changes to the system. The behavior is consistent with their use and offers little chance of user error.

The following graphical user interface (GUI) terms are used herein.

Window: A window refers to a rectangular box on a computer display.

Pop-up Window: A pop-up window is a window that pops up in response to a mouse or button click.

Dialog Box: A dialog box is a popup window that allows additional information to be provided by a user.

Message Box: A Message Box is a popup window that displays important information from the MS. Message boxes usually display warning or error messages.

Check Box: A check box allows the user to select an option.

Button: Click the button to execute the command written on the button.

Radio Button: A radio button allows the user to select one of many options.

Field: An area of a window or dialog box in which the user can enter information or the system displays the information.

Drop-down List: A list of items that appears when the user clicks the down arrow located to the right of the drop-down list.

How the system is displayed and configured

The MS is displayed and organized in a hierarchical structure containing a 3x3 matrix. The functional views-motion view, cross-linked map view and steering view-form the column headers of the MS matrix. Each of these views supports the following entity levels: shelf, equipment, and interface (end points) as row headers. This module approach makes the system easier to understand. Each display is also well organized, clear and easy to see. As a result, it is relatively simple for the user to move through the system by clicking on any function at any time and practicing to move up and down to another entity level. For example, a user can configure the Shelf Manager (SM) timing source by clicking on the action view button and practicing descending to the equipment screen. This approach and layout greatly facilitates the operation, maintenance and monitoring of the LAS shelf.

The 3x3 matrix for MS is

Screen layout

Referring to FIG. 17, the displayed MS display is divided into four regions or regions. From top to bottom, the regions are named Region A, Region A1, Region B, and Region C. The system is designed so that all areas are always visible and not be confused with other windows. The advantage of this window structure is that certain information and complete system information are always available to the user. An additional advantage is that the user's computer screen never gets messy with small windows and dialog boxes.

Region A shown in FIG. 18 includes elements toolbar 202, shelf drop-down list 204, and session indicator 206. Each of these Region A elements is described below.

A toolbar is a panel of icon buttons that represent commands or controls. There are three groups of buttons: progress 200, view 210 and control 212. Each group provides quick access to commonly used functions as defined in Table 12 below.

Table 12

Shelf Drop-Down List (204)

The shelf drop-down list is a list of shelf node identification numbers. Clicking down arrow 214 allows the user to select a shelf to monitor.

Session Indicator (206)

The session indicator has the following color coded means of Table 13.

Table 13

The following table describes the transition features for the session indicator.

Table 14

Region A1 of FIG. 19 includes shelf descriptor 220 and screen level descriptor 222 information. Shelf descriptor 220 identifies the interface to the current shelf, slots, and screen being displayed. Additional information may appear in area A1, depending on the screen you are viewing. Screen level descriptor 222 identifies the current screen and entity level (shelf, equipment or interface) displayed by a particular view (action, cross map or management).

Region B of FIG. 20 includes content that changes depending on the current function. Most user interaction takes place in region B. The first screen represents an operational view-shelf. The screen content of this area is determined by the active view button located in area A. All Zone B screens have the next level of visibility in the system.

When the user successfully completes the login to the system and clicks the action view button, the user sees all the modules of the current shelf at the top level. Next, when the user clicks on a particular module, an enlarged view of the selected module and the supply information associated with this module are displayed, which is the second level. Finally, if the user clicks on any interface of the selected module, the user is moved to the third level, where the user can access the interface information.

Region C shown in FIG. 21 includes equipment and interface LEDs. Table 15 below describes the LED states.

Table 15

To log in to the MS, the user selects the shelf ID to configure from the shelf drop-down list and clicks the start session button. A security window appears asking the user to enter a username and password. When the user enters a username and password, a database main option (not shown) appears with choices to extract configuration information from the shelf or to use the configuration information stored in the MS database. After the user makes a selection, the system initiates data synchronization so that the SM information is uploaded and displayed on the PC screen. Until this process is completed, the user cannot enter any operation of the MS. Once the data synchronization process is complete, the operational view-shelf screen appears as previously shown in FIG. 17.

Composition overview

The MS provides a real time representation of the LAS system. All LAS module types such as SDSL, 2DSX1, 4BRI, 4POTS, 4POTSR, 2CPOTS and 2OCU are represented and their operating conditions are displayed. Before the user makes any changes to the system, all changes are shown in red for improved visibility. Microsoft supports asynchronous connections to one LAS Shelf at a time.

Equipment level

Equipment level display area B, the second level provides a wider equipment representation. In addition, configuration tabs are provided that represent means for changing the current equipment configuration and parameters as needed. The installed device type appears when it differs from the required configuration. A user's device configuration timestamp and a display that has performed the most recent configuration change are also provided. From the equipment display, the user can select a particular interface by clicking on the associated button 1-4. This moves the user to the interface level.

Interface level

Interface level display area B, the third level also shows a wider equipment representation. A configuration tab is provided that represents means for changing the current interface configuration and parameters as needed. An interface configuration timestamp and a display of the user who performed the most recent configuration change are also provided.

Configure SM

To configure the clock management of the SM, the installed equipment type is automatically detected and appears in the installed eq type field. The SM is preconfigured for the 26th slot. As shown in FIG. 22, to set the timing source, the user clicks on the SM slot in region B and clicks on the configuration tab 230. As shown in FIG. 23, one of the first, second and third synchronization sources is selected. It is noted that the current timing field 232 displays the active timing source. Examples of configurations for some modules are described.

Configure SDSL

The SDSL module receives configuration and selection information from the SM through the control interface via the backplane bus on the LAS shelf. As shown in Figure 24, to configure the equipment type, the user clicks on the slot with the SDSL label on the action view-shelf screen, clicks on the configuration tab 230, and clicks SDSL in the eq type drop-down list. do. Selectable user data rates from the SDSL interface include 256 kbps, 384 kbps, 512 kbps, 768 kbps and 1152 kbps.

As shown in FIG. 25, to configure the interface characteristics for the SDSL module, the user clicks on Region B's interface button or Region C's interface LED, clicks Configuration tab 230, and the Data Rate drop-down list. Select the data rate from 232 and select the seal current 234 on or off option.

4POTS / 4POTSR Configuration

The 4POTS module is useful for long loop applications with the possibility of bulk ringing from an external ringing generator. For short loop applications, if there is no possibility of bulk ringing use, a 4POTSR module with ringing capability on board may be used. To configure the 4POTS device type, the user clicks the slot-shelf screen with the 4POTS label in the Actions view, clicks the Configuration tab, and clicks 4POTS in the drop-down list of type eq. As shown in FIG. 26, to configure the interface characteristics, the user clicks on the interface button of region B or the interface LED of region C, clicks the configuration tab 230, and the transmission type of the on-hook transmission drop-down list. (236) is selected.

Event and alert reporting

State changes, alerts, and changes initiated by all users become the event's occurrence and timestamp logs. These changes provide an audit trail for the operation of the LAS system. In the case of a change initiated by the user, the user who performed the change is also noticed in the event (see FIG. 27). The MS user can select the presentation format, filter events (eg, major, minor, etc.) by type, time of occurrence, and number of events to display. In addition, the displays may be arranged in increasing or decreasing order, or may not be aligned at all. These options may be stored forever for future applications to the event, or may be tentatively modified for specific needs (see FIG. 28).

Shelf (shelf manager)

The shelf that the user selects provides the underlying context to the display. All events related to all the equipment and interfaces of the shelf are displayed.

Equipment level

Typical equipment events for equipment insertion and removal, state changes, and configuration changes are generated and logged. The selected equipment provides the basic context to the display. Only events related to the selected device are displayed.

Interface level

Typical interface events for state changes, alerts, and configuration changes are generated and logged. The interface provides a basic context for the display. Events related to the selected interface are displayed.

Cross-connection mapping

The connection between various devices and interfaces and timeslots is controlled by this feature. In this case, this information is selected, displayed and transformed into the LAS operating layer.

Shelf display

The shelf display provides the user with a representation of the connections between the devices in the shelf. The user selects a slot and the associated connected devices are highlighted (see FIG. 29). For more detailed connection information, the device can be double clicked.

Equipment display

The device display (see FIG. 30) provides the user with a representation of all connections associated with the interface of the selected device. A vivid and detailed representation of the equipment is also provided. The user can select a key specific connection to view the equipment at the other end of the connection. Once the desired connection is found, the connection can be double clicked to narrow the focus to the interface.

Interface display

The interface display (see Figure 31) provides the user with a representation of all timeslots associated with the connection on the selected interface. It also provides a vivid and detailed representation of the equipment. The user can select a key specific connection to view the equipment on the other side of the connection. Once the desired timeslot is identified, the user is given the opportunity to change the connection.

Active operating conditions

The MS provides active operating conditions and equipment presence displays. The display, along with its operating conditions, accurately describes the shelf and all cards, including detection of insertions, removals, configured cards, and so on. System card types are represented, including SDSL, DSX, BRI, POTS, POTSR and OCU.

Shelf display

The shelf display provides a representation of the LAS shelf. This includes all operational LES and card representations and more. Objects that resemble real hardware are generated, making it easier for users to recognize components and use the system. From the shelf display, the user can select a particular device by clicking on it. By clicking on a slot in the shelf view, the user moves to the equipment level, which provides a more detailed view of the selected equipment.

Equipment display

The instrument level display provides an instrument representation that includes wider and more detailed labeling than the shelf display. In addition, a status tab is provided that indicates equipment status (in service, not in service) and the time of the most recent status change. A method is provided for manually changing equipment status. A display of the user who has performed the most recent manual state change is also provided. From the equipment display, the user can select a particular interface by clicking (buttons 1-4). This moves the user to the interface level.

Interface display

The interface level display provides the same detailed equipment representation, including labeling. Status tabs are provided that indicate the interface status (in service, not in service) and the time of the most recent state change. A method is provided for manually changing the interface state. A display of the user who has performed the most recent manual state change is also provided.

Several views from the view matrix are described below.

Action View-Shelf

Operational View-The shelf screen displays a realistic view of the front of the shelf as shown in FIG. 17 above. The screen displays 26 clickable objects, each representing a slot on the active shelf. Each entity contains an equipment type text label and an LED applicable to the equipment type installed. LED display areas whose status is not currently transmitted to the SM are grayed out. The shading and LED color of the slots have four possible conditions: empty and unsupplied, empty and pre-supplied, RM inserted and not supplied, and RM inserted and supplied.

The control functions belonging to this screen are as follows. Each device screen area is an active area that, when clicked, brings the zoom to the action view-device screen. The user can also click the numbered buttons located below each screen to get the same results. A single left click will take you to the Action View-Equipment-Status tab, which is applicable to Area B equipment.

Action View-Equipment: Resource Module

Operation view-equipment: The RM screen displays a representation of the instrument screen, as shown in FIG. 32, and allows the user to enter or modify the following actions, namely the instrument type; place the instrument in or out of service; Reviewing the complete set of attributes of the equipment; And transition to the next level, that is, the interface level. Shelf descriptor 220 "shelf 1 (central station) slot 24" and screen level descriptor 222 "operation view-equipment" of this screen are displayed in region A1. In this screen, area B is composed of two components, an RM screen 240 and a tab dialog box 242.

The screen is the actual representation of the RM. In this example, the name, 2DSX1, appears at the top of the screen. Each LED is a real time display indicator for this RM. This RM number, for example 24, is at the bottom of the screen. Two I / F buttons 250 associated with this RM are immediately displayed on the right side of the screen. The user can drill down the level by clicking on the I / F button to view and change information related to this RM. For example, the user can click the I / F 01 button to change to the interface level for I / F 01.

On the right side of the screen is a larger dialog box with four tabs 252, namely Status, Configuration, Events, and Actions. The following functionality is included in each tab. Read-only items are marked with "RO". Read-write fields are marked with "RW".

condition

Condition (RW)

Optional: In Service, Not In Service

Date and time change (R0)

Previous condition (RO)

Install / Remove

Most recent manual state change date / time and user ID (R0)

Configuration

Equipment type (RW)

Options: NONE, 4BRI, 2DSX1, 2OCU, SDSL, 4POTS, 4POTSR, 4POTS +, 2T1,2T1 +, 2SDSL, SRU, EPRM2

Software version (RO)

Channel number (RO)

Installed equipment type (RO)

Most recent manual state change date / time and user ID (RO)

event

Date / Time (RO)

Slot (RO)

Interface (RO)

Severity (RO)

Event type (RO)

Performance

Behavior View-Equipment: Shelf Manager

Action view equipment: SM screen, shelf descriptor "shelf 1 (central station) slot 26" and screen level descriptor "action view equipment" are displayed in area A1. In this screen, area B is composed of two components, namely SM screen 240 and tab dialog box 242, as shown in FIG.

The screen is the actual representation of the SM. In this example, the name, SM, appears at the top of the screen. Each LED is a real time display indicator for the SM. SMU slot number 26 is located at the bottom of the screen.

On the right side of the screen is a larger dialog box consisting of four tabs 252: Status, Configuration, Events, and Performance. The following functionality is included in each tab. Items that are read only are marked with "RO". Read-write fields are marked with "RW".

condition

Condition (RW)

Optional: In Service, Not In Service

Date and time change (RO)

Previous condition (RO)

Install / Uninstall

Most recent manual state change date / time and user ID (RO)

Configuration

Equipment type (RO)

Shelf Number (RW)

Current timing (RO)

Sync source (RW)

1st RM

Options: 1-25; office ; NONE

1st I / F

Options: 1-25; office ; NONE

2 RM

Options: 1-25; office ; NONE

Second I / F

Options: 1-4; NONE

3 RM

Options: 1-25; office ; NONE

3 RM

option; 1-4; NONE

Activation (RM)

ACO (RW)

Most recent manual state change date / time and user ID (RO)

event

Date / Time (RO)

Slot (RO)

Interface (RO)

Depth (RO)

Event type (RO)

Performance

Motion view-interface

Operation view interface screen, shelf descriptor 220 "shelf 1 (central station) slot 24 interface 1" and screen level descriptor 226 "action view interface" are displayed in region A1. In this screen, area B consists of two components, RM screen 240 and tab dialog box 242, as shown in FIG.

The screen is the actual representation of the RM. In this example, the name 2DXS1 appears at the top of the screen. Each LED is a real time display for this RM. At the bottom of the screen is the number RM, 24. The two I / F buttons associated with this RM are shown directly on the right side of the screen. Note that the color of I / F 01 is black. This indicates that I / F 01 represents the current view. By clicking the I / F 02 button, the user can view data specific to the interface 2. When the user clicks on I / F 02 the color is black, indicating that this is the current view.

On the right side of the screen there are five tabs 252, a dialog box consisting of status, configuration, events, performance and maintenance. The following functionality is included in each tab. Items that are read only are marked with "RO". Read-write fields are marked with "RW".

condition

Condition (RW)

Option: in service, not in service

Date and time change (RO)

Previous condition (RO)

Install / Uninstall

Most recent manual state change date / time and user ID (RO)

Configuration

Framing Format (RW)

Option: ESF, SF

Line code (RW)

Option: B8ZS, AMI

Equalization (RW)

Options: 0 to 133 ft, 133 to 266 ft, 266 to 399 ft, 399 to 533 ft, 533 to 655 ft

Most recent manual state change date / time and user ID (RO)

event

Date / Time (RO)

Slot (RO)

Interface (RO)

Depth (RO)

Event type (RO)

Performance

Cross-Connect Map View-Shelves

This screen is reached by clicking on board 7 of the "Cross-connected map view-shelf" screen.

Connected from the interface slot and connected to the interface slot

The screen for board 7 is displayed in region B1 and its interface connection is displayed in region B (middle part of FIG. 36). At this time, nothing is displayed in area B3. The currently selected interface button is colored black (the user can select it by clicking the interface button). Unselected buttons are blue. Slot 7 is shown with four interface buttons 260 in the center of the M-intermediate. Around it is a button 262 labeled 24-01. There is also a blue line 264 connecting buttons 07-01 and 24-01. This indicates that the interface 01 of the slot 24 is connected to the interface 01 of the slot 07. In this case, slot 7 is connected from slot 266 and slot 24 is connected to slot 268 (FIG. 37).

View The Connected-To faceplate

When the user clicks on one of the ones connected to the interface button, the screen of the slot associated with this interface button appears in area B3, in this case slot 24. In addition, the color of the connecting line between the two sets of interface buttons of the area B2 is changed to black, and the color of the button connected to the interface is also changed to black. The purpose of the color change is to highlight the selected connection. By clicking on the buttons connected to each interface, the user can see the associated screen as shown in FIG.

Cross-Connection Map View-Interface

To drill down the equipment screen to the next level. The user clicks on the enabled interface along the screen of area B3. This allows the user to see the cross-linked map view-the interface screen. Regions B1 and B3 maintain their original screen image. However, area B-median changed. This displays timeslot matrix 270 and displays timeslot buttons 266, 268 from " TS " and " TS " (TS indicates timeslot). Each button in the matrix is blue, indicating that the user has not selected any buttons for further viewing. In addition, the number of slots, interfaces and timeslots is printed on each button. For example, the buttons in row 2, column 1, labeled 07-01-02 indicate that this is a timeslot associated with slot 7, interface 1, timeslot 2. These features are shown in FIG. 37.

Select timeslot

To drill down to an additional level, the user clicks one of the timeslot buttons. The user will know that the color of the timeslots "From TS" and "From TS" that the user has selected will change to black. In addition, any other timeslot buttons grouped with the user-selected connection are also black. If this happens, the user will see a button 280 of Conn / Disc Sel'd Ts appear. In FIG. 38, this button caption represents "Connect / Disconnect Selected Timeslot".

Cross Link Map View-Interface: Link Dialog Box

The user can click the Conn / Disc Sel's button to bring up the connection dialog box as shown in FIG. The upper portion of this dialog box shows the number information of the current start timeslot 282, the end timeslot 284 and the affected timeslot 286. In this example, since the timeslots start with 1 and end with 3, the number of timeslots affected is 3. Disconnect button 290 allows the user to disconnect the currently connected timeslot. Disconnection is enabled for valid connections. The connect button 288 allows the user to connect timeslots that currently have no connection.

If the user clicks the lock button 292, the system will "remember" the timeslot. This is only enabled for interfaces that do not have an associated connection. This will be evident when the user sees the word "unallocated" in the time slot area "to TS". After the user clicks the lock button, the user can perform other operations of the MS and return to this screen. That is, the system "remembers" locked timeslots. For example, the user may select another timeslot to which the user wishes to connect to being locked. However, this requires moving to another screen and returning. When the user returns, the "remembered" timeslot and the newly selected will appear. The user does not have to reenter the information.

Changing parameters

If the word "unallocated" does not appear anywhere in the "from TS" and "to TS" times, there is a connection between the two timeslots. As in this case, if there is a connection, a number of user changeable input boxes will appear at the bottom of this dialog as shown in area B of FIG. 40.

Adjustable view-shelf

Adjustment View-Shelf screen displays a substantial view of the front of the shelf as shown in FIG. 40/41. There are 26 clickable entities 294, each representing a slot in an active shelf. Each entity contains an equipment type text label and an LED applicable to the equipment type installed. LED display areas whose status is not currently communicated to the SM are grayed out.

Adjustable view-equipment

Control View-Clicking on the shelf's Resources module will display the Control View Equipment screen in Area B. In this screen, as shown in Fig. 42, a screen of the RM and a three tab (user profile, recording and retrieval) dialog box 296 are displayed. The user can change the current user ID and password by entering appropriate information in the user profile dialog box 298. After the user has made all changes to the MS, the user can click the Backup Database NOW button 295 to write the database to the hard disk. The user can restore the database by clicking the Restore Database NOW button (297).

Adjustable view-interface

The adjustment view-interface screen supports the function as the adjustment view-equipment screen shown in FIG. 43.

Software structure for Microsoft

This section describes some requirements that affect the structure chosen for this software. To the user, MS is a single executable program that supports DLLs, data files, and INI files, and runs on a PC using Windows 95, Windows 98, or Windows NT 4.0. The program provides the ability to monitor and configure and control LAS equipment through a single, consistent user interface.

The user interface represents a single, well-defined window where all user interaction takes place through this window, providing a framework common to all monitoring and configuration actions. Common frameworks allow users to learn Microsoft faster by repeating familiar frameworks during all operations. The PC is connected to the LAS device via a cable (serial or LAN). Communication with the LAS hardware occurs to the user, and the results of this communication are automatically reflected in the user interface (i.e., if the data presented on the component changes, each display is "live" and without user intervention). Is updated).

Context diagram (Figure 44)

This section describes the context in which MS software operates. As discussed above, the PC 300 on which the MS runs is connected to the LAS equipment 14 via a cable 302 (serial or LAN). The user receives the output from the MS through a single window appearing on the display 308 and sometimes interacts with the software by using the mouse 304 primarily with keyboard 306 input (enter username and password). . Various information items are permanently stored on the PC hardware for program use. These items include a configuration database for LAS equipment, user-selected options and program configuration settings and configuration information for the communication link between the PC and the LAS.

Data flow (Figure 45)

Due to the requirement that the user interface display be "live", ie automatically updated in real time to reflect the conditions of the connected equipment, several separate threads of execution from the subsystem communicating the user interface with the LAS equipment Used in software. 45, the top level data flow diagram, shows data flowing between and to and from external elements. As shown, the user interface, communication reader, and communication recorder are each separate threads of execution.

Database description (Figure 45)

Database 30 includes configuration, conditions, events, and historical data about LAS equipment managed by the MS. This data is made available to the user interface 312 that the user can control based on the requirements imposed on the user interface. The data manager 314 module provides an encapsulated interface to the database and provides intelligent learning / setting functions that adjust the many internal results that change each piece of data.

The data structure of the database is an object-oriented structure, created in a hierarchy that mimics the hierarchy of LAS equipment. At the top level, there is a Node object, which represents a group of shelf structures. Each shelf consists of a number of slot structures, and each slot contains a number of port structures. There are several types of ports, all of which are assumed to be the same type.

Therefore, specific information about LAS equipment is modularized into only a few categories. This modularization is further done so that each type of equipment can be represented by one classification throughout the system. This encapsulation is very maintainable, very changeable, and reduces the cost and time required to include further changes in the future.

For each shelf, there is an Event History, which contains all the events that occurred for the elements of this shelf. In addition, each shelf has Timing Info, which describes how to obtain and manage the clock signal for the shelf.

Microsoft builds on Microsoft Visual C ++ on top of Microsoft Windows 95 and Windows NT 4.0. The Microsoft Foundation Classes (MFC) application framework is also used to make the enhanced GUI elements that already exist in Windows and Win32 work in MS software. Visual C ++ is the de facto industry standard because it is the world's most widely used software development platform. The MFC application framework provided with Visual C ++ is equally well known. Like other VC ++ / MFC applications, moving to UNIX or other operating systems, integrating with JAVA-based applications, and so on is easily accomplished without the limitations that exist in other languages.

Communication with the LAS equipment is performed in an execution thread separate from the user interface thread. This makes the user interface responsive and also allows the user to receive update information from connected equipment at the same time as the user is performing some action. Encapsulating communication in this way allows communication subsystems to be modular, easily modified and upgraded. This is particularly useful when either physical or data links are used to communicate with the LAS equipment.

Fiber Access to Resource Modules

Any source module 10 is required to have a fiber optic interface. In order to preserve the interchangeability of the modules, fiber access to these modules must be common to these particular modules to achieve the goal of providing any type of service in any shelf slot. Therefore, in accordance with the preferred embodiment of the present invention of FIG. 46, a fiber optic cable entry slot or window 401 (about 1 length) is provided in the upper rail 402 of each module chassis 404 to provide fiber 406. ) Can be inserted from above the shelf (not shown) and between the slots of the shelf to mate with the optical fiber transceiver 408 (to the extent provided in the module). The basic method of routing the cable is shown in FIG. 46. The roof of the shelf provides a way to protect the cable near the entry point. A fixed amount of cable slack is made to reach the transceiver 408 located near the bottom half of the backplane connector 410. The cable slack provided by the loop 412 is sufficient to allow the RM 10 to be partially removed without applying pressure to the cable 406. The mechanical stop mechanism 414 prevents the RM from being removed before the damaging pressure is applied to the fiber / cable. Additional optional elements (not shown) are covered, which will prevent loose cables from catching on surface components. Special attention should be paid to the component heights in the loose cable area. Sufficient slack should be present in the cable to guide the cable along the upper edge of the printed circuit board (PCB) during removal to avoid tall components on the PCB 416.

In this embodiment the following advantages are achieved.

Set the screen design and indicator LEDs (not shown) on screen 417 to match all other RMs.

Can be retrofitted to the field

To accommodate a wide bending radius of the fibers 406.

Allow fibers to be placed from the rear of the unit.

Allow any number of fiber interfaces to be employed.

Other media may be employed (ie DS3 coaxial, RJ48, etc.).

The mechanical stop mechanism 414 is further displaced by the attractive engagement with the stop 420 on the underside 404 of the special module 10 using the shelf's lower rail while removing the RM 10. prevent displacement.

Disconnection protocol and message channel

A single wire serial interface connects each RM slot to an SM slot through the backplane. Before module 10 can communicate, a message from a message channel that accepts access to the backplane must be delivered. One interface is dedicated to each RM.

This section describes the disconnection initiation and teardown protocol interfaces used to accept removal of backplane access to newly inserted modules or backplane access from wrong modules. Chart 1 shows the steps required to accept the backplane access protocol. These steps are implemented using the Dallas semiconductor chip described in data sheet DS2405 (Ref. 15), which semiconductor chips have been improved in accordance with the present invention.

Chart 1. Backplane Access Consent

Step 1.

When power is applied, i. xx is replaced by the actual slot and the resource module is inserted. For example, the resource module in slot 05 would control CNTL05 as its one-bit serial connection.

Insertion of the RM will cause the 1-bit serial line CNTLxx to be pulled high.

Step 2.

The SM detects that the CNTLxx line is high. This informs the SM that an RM has been inserted.

Step 3. Wait for Timer

The fact that the RM signals its presence does not mean that the RM's processor has completed the download. The SM waits at least 3 seconds to receive the CNTLxx signal and communicate with that RM. This allows the RM enough time to complete the POTS.

Step 4. Reset Pulse

The shelf manager initiates a reset pulse on the CNTLxx line when the timer expires. This is a "low" pulse that is held longer than 480 Hz (see Ref. 15 for more details).

Step 5. Presence Pulse

When the RM detects a reset pulse, it initiates a presence pulse on the CNTLxx line. This is a " low " pulse lasting 60 ms < = pulses < 240 ms (see Dallas Semiconductor Automatic Identification Data Book for more details). The presence pulse informs the SM that the RM's addressable switch (AS) is alive and available.

Step 6. Read ROM Command

This command is sent from the SM to the RM addressable switch. This command requires a family code and serial number from the AS. As specified in Ref. 5, the shelf manager sends 33h to the addressable switch. This protocol requires pulling the CNTLxx line low for 15ms and placing one bit on that line. This is repeated until all eight bits or ROM commands have been delivered.

Step 7. ROM ID

The RM provides identification information as specified in Ref. 15. This is a 64-bit sequence, the first eight bits are the family code, the next 48 bits are the device-specific serial number, followed by eight CRC bits. Upon receiving this information, the SM verifies the family code and justifies the CRC. The CRC polynomial is x ⁸ + x ⁵ + x ⁴ +1.

Step 8. Request the POTS Results

The SM requests the POTS result from the RM. The SM transmits 01101011 bits, with the least significant bit first, on the CNTLxx line using a 100 ms pulse width for each bit. The RM monitors the CNTLxx lines for specific request POTS result bit patterns.

Step 9. POTS Results

The RM responds with an SM POTS result message with a POTS result. This is a bit mask and one bit represents "pass" for POTS test and 0 represents "fail" for POTS test. This allows the SM to know the results of each test. The RM sends the 01101011 bit pattern to the SM as the POTS result preamble, with the least significant bit first. This results in a POTS result as shown in Table 16.

Table 16

Report POST Results

If test is not defined, returns 1

Step 10. ROM Command Matching

The command is passed from the SM to the addressable switch of the RM (as specified in reference 15). After confirming the ROM ID, 55h with the ROM ID information is returned to the addressable switch. An addressable switch receiving a 64-bit RIM ID sequence causes the device to be enabled if the current device is disabled and disabled if it is enabled. In other words, it is used as an on / off switch for an addressable switch.

Step 11. Read Data Strobe

To verify that the resource module addressable switch is enabled, the SM performs a data strobe read on the CNTLxx line. This is limited to "low" pulse duration 1 ms <= pulse <= 15 ms (see reference 15 for details). If the CNTLxx line returns high, then the addressable switch is disabled.

Step 12. Addressable Switch Status

Upon receiving a data strobe read, the addressable switch pulses the CNTLxx line “high” when enabled. This is defined as a high pulse lasting 0 <= pulse <= 45 ms (see Dallas Semiconductor Automatic Identification Data Book for details). When the addressable switch is disabled, the CNTLxx line is pulsed "low". This is defined as a low pulse that lasts for 0 <= pulse <= 45 ms (see reference 15 for details).

Step 13. Remove Module Backplane Access

When the shelf manager detects a faulty module, it must initiate a reset pulse on the CNTLxx line. This is defined as a low pulse that lasts longer than 480 ms. The initialization of the reset pulse is to remove the faulty module from the backplane access.

Message Channel Initiation Procedure

See chart 2.

Step 1. Identify the Module

The SM requests an RM to identify itself whenever a new RM is inserted or the shelf is up. The SM sends a MSG_GET S_RM_ID message.

Step 2.

The resource module responds with a MSG_ACK S_RM_ID receipt notification message. The message status field indicates "OK" if the request was processed without error. The payload message has rm_eqpt_attr information to identify the RM for the SM.

Step 3.

The resource module service state setting is initialized by the SM. The SM transmits an MSG_SET S_RM_PROV OP_PROV_RM_SYS message to the RM requesting a service state change. The rm_eqpt_attr payload is carried in a message with a modified primary service state (PST).

Step 4.

Optionally, the RM receiving the modified primary service status message responds with a MSG_ACK S_RM_PROV OP_PROV_RM_SYS receive notification message. A "in progress" status return value informs the SM that the message was received without error but that the message was not fully processed.

Step 5.

When the RM has processed and performed the changed primary service state, the RM sends a MSG_ACK S_RM_PROV OP_PROV_RM_SYS message. The "OK" status return value informs the SM that the processing of the changed primary service state is complete.

Chart 2. Insertion Module

Step 6.

RM configuration is initiated by the SM. The SM sends an MSG_SET S_RM_PROV OP_PROV _RM_FACIL message to the RM end point requiring a new / updated configuration parameter with a term_pt_attr payload (see the Copper-LINC Object Model document for a detailed description of the term_pt_attr property).

Step 7.

Optionally, the resource module receiving the configuration parameter message responds with a MSG_ACK S_RM_PROV OP_PROV OP_PROV_RM_FACIL receipt notification message. A return value of "in progress" indicates to the SM that the message was received without error but the message was not fully processed within the resource module.

Step 8.

The RM sends an MSG_ACK S_RM_PROV OP_PROV_RM_FACIL message when the RM has processed and performed the updated configuration parameters. The "OK" status return value informs the SM that the processing of the new configuration parameter is complete.

Service Module Configuration

A diagram of the performed steps when a resource module is configured for a service is shown in chart 3.

Chart 3. Changing module service states in services

The RM service state setting is controlled by the SM. The SM sends a MSG_SET S_RM_PROV OP_PROV_RM_SYS message to each resource module requesting a service state change. The rm_eqpt_attr payload is sent in the message with the modified PST.

Step 2.

Optionally, the RM receiving the modified primary service status message responds with an MSG_ACK S_RM_PROV OP_PROV_RM_SYS acknowledgment notification message. A "in progress" status return value informs the shelf manager that the message was received without error, but the message was not fully processed.

Step 3.

When the RM processes and performs the changed first service state, the resource module sends an MSG_ACK S_RM_PROV OP_PROV_RM_SYS message. The "OK" status return value informs the shelf manager that the processing of the modified primary service state is complete.

The sequence is repeated for each module that requires a service state change. An RM configured for a service without a configuration parameter message operates at the startup error setting.

Change module service state

Chart 4 is a diagram of a step for generating a module service state change other than the service accompanied by the description of the step.

Step 1.

The RM service state setting is controlled by the SM. The SM transmits an MSG_SET S_RM_PROV OP_PROV_RM_SYS message to each RM requesting a service state change. The rm_eqpt_attr payload is sent in the message with the modified PST.

Chart 4. Changing the status of a module service that is not in service

Step 2.

Optionally, the RM receiving the primary service status message responds with a MSG_ACK S_RM_PROV OP_PROV_RM_SYS receive notification message. A "in progress" status return value informs the shelf manager that the message was received without error, but the message was not fully processed.

Step 3.

The RM sends the MSG_ACK S_RM_PROV OP_PROV_RM_SYS message when the RM processes and performs the modified primary service state. The "OK" status return value informs the shelf manager that the processing of the changed service state is complete.

The sequence is repeated for each module that requires a service state change. An RM configured for a service without configuration parameters operates at the startup error setting.

Step 4.

Non-service RM configurations require notification to supported entities. The SM sends a MSG_SET S_RM_STATE OP_STATE_RM_FACIL message to each RM end point with a changed primary service state as part of the rm_term_pt_cond property.

Step 5.

The RM receiving the end point primary service status message responds with an MSG_ACK S_RM_STATE OP_STATE_RM_FACIL receipt notification message indicating to the SM that the message was received without error, but the message was not fully processed.

Step 6.

The RM sends a MSG_ACK S_RM_STATE OP_STATE_RM_FACIL message when the RM processes and performs the modified end point primary service state. The "OK" status return value informs the SM that the processing of the modified primary service state is complete.

End point configuration changes

Chart 5 describes the steps that occur to change the resource module end point parameter configuration.

Chart 5. End Point Configuration Changes

Step 1.

RM end point configuration changes are initiated by the SM. The SM sends a MSG_SET S_RM_PROV OP_PROV_RM_FACIL message to each end point requesting a change. The term_pt_attr payload is carried in the message.

Step 2.

The RM receiving the change configuration message optionally responds with an MSG_ACK S_RM_PROV OP_PROV_RM_FACIL receipt notification message that informs the SM that the message was received without error but the message was not fully processed.

Step 3.

If the RM processes and performs the changed configuration, the RM sends an MSG_ACK S_RM_PROV OP_PROV_RM_FACIL message. An "OK" status return value informs the SM that the processing of the changed configuration is complete. Status conditions and alerts at the end point are included in the message as applicable.

The sequence is repeated for each end point change.

Remove module

The section describes the steps required when the RM is removed from the system.

Physical removal of the supported entity resource module is detected on the CNTLxx line for the SM and internally the SM constitutes an out-of-service RM as described in connection with Chart 4.

Physical removal of the supporting entity RM has a stronger impact on the system than removal of the supported entity RM. If the supporting entity is the primary or secondary timing source, the SM allocates a new timing source. When the supporting entity transmits the supported entity data, the supported entity RM is placed outside the service. Chart 6 is a diagram of the steps that occur.

Chart 6. Physically removed entity resource modules

Change timing source

Step 1

The primary or secondary timing source change requires an end point parameter message transmission by the SM. The SM sends an MSG_SET S_RM_PROV OP_PROV_RM_FACIL message to an RM end point that may be the timing source.

Step 2

Receiving a configuration parameter, the RM responds with an MSG_ACK S_RM_PROV OP_PROV_RM_FACIL receipt notification message indicating to the SM that the message was received without error but the message was not fully processed in the RM.

Step 3

When the RM processes and performs the updated configuration parameters, the RM sends a MSG_ACK S_RM_PROV OP_PROV_RM_FACIL message. An "OK" status return value informs the SM that the processing of the new configuration parameter is complete.

Support for entity accident states

Step 1

Removal of supporting entity RMs may require the deployment of supported entity RMs other than services because of the supporting entity accident state. The SM sends the MSG_SET S_RM_STATE_RM_FACIL message to each RM end point with the changed primary service state as part of the rm_term_pt_cond property. This allows the resource module to enter the Out of Service-Supporting Entity Outage (OOS-SGEO) state.

Step 2

The RM receiving the end point primary service status message responds with an MSG_ACK S_RM_STATE OP_STATE OP_STATE_RM_FACIL receipt notification message indicating to the SM that the message was received without error but the message was not fully processed.

Step 3

If the resource module has processed and performed the modified end point primary service state, the resource module sends an MSG_ACK S_RM_STATE OP_STATE_RM_FACIL message. The "OK" status return value informs the SM that the processing of the changed primary service state is complete.

Reporting alarm

The RM, capable of detecting alarms, voluntarily reports an alarm to the SM. Automatic reporting, when referring to chart 7, occurs when the alert is set or cleared.

Chart 7. Alarm Reporting

Step 1

When the RM end point detects an alert, the point requests notification to the SM, and the RM sends an MSG_A_INFO S_RM_SIG_EVENT_ALARM message specifying the alert type and setting or clear status.

Step 2

The SM responds with an MSG_A_ACK S_RM_SIG_EVENT OP_EVENT_ALARM message. An "OK" status return value informs the RM that the alert message has been received and processed.

Report condition

The RM capable of detecting a condition voluntarily reports the condition to the SM, as described in chart 8.

Chart 8. Condition Reporting

Step 1.

The RM end point detects a change in condition. The RM transmits an MSG_A_INFO S_RM_SIG_EVENT OP_EVENT_GEN message specifying the condition code.

Step 2.

The SM responds with an MSG_A_ACK S_RM_SIG_EVENT OP_EVENT_GEN message that informs the RM that a condition message has been received and processed.

Status Information Request

The SM may collect state information about the RM equipment or the RM end point. Chart 9 is a diagram of the steps taken to collect status information followed by the description of the operation.

Chart 9. Status Information Needs

Step 1.

The SM sends a MSG_GET S_RM_STATE OP_STATE_RM_SYS message to request the equipment level status from the RM.

Step 2.

The RM responds to the SM with an optional MSG_ACK S_RM_STATE OP_STATE_RM_SYS receipt notification message informing the SM that the request was received without a transmission error.

Step 3.

After processing the message, the RM sends an MSG_ACK S_RM_STATE OP_STATE_RM_SYS message with the "OK" status of the rm_eqpt_cond and rm_eqpt_alarm attributes.

Step 4.

The SM sends an MSG_GET S_RM_STATE_RM_FACIL message to request the end point status from the RM.

Step 5.

The RM responds with an MSG_ACK S_RM_STATE OP_STATE_RM_FACIL message to inform the SM that the request was received without a transmission error.

Step 6.

After processing the message, the RM sends an MSG_ACK S_RM_STATE OP_STATE_RM_FACIL message with the "OK" status of the term_pt_cond and term_pt_alarm properties.

Status to Monitor End Point Performance

The SM may also collect performance monitoring status for each RM end point. Chart 10 describes the steps that occur to collect performance monitoring status.

Chart 10. Performance Monitoring Status Requirements

Step 1.

The SM sends a MSG_GET S_RM_STATE OP_STATE_RM_PM message to request the end point performance monitoring status from the RM.

Step 2.

The RM responds with an MSG_ACK S_RM_STATE OP_STATE_RM_PM message indicating to the SM that the request has been received without a transmission error.

Step 3.

After processing the message, the RM sends an MSG_ACK S_RM_STATE OP_STATE_RM_PM message and term_pt_attr_pm with "OK" status.

Keep alive

The RM monitors traffic sent to the SM. If the RM did not deliver to the SM within the last 3 seconds, then the RM sends an activity keep message to the SM as shown in chart 11. The keep active message informs the SM that the RM is still in system operation.

Chart 11. Stay active

The message does not require receipt notification from the SM.

maintain

The section describes the operations that occur to operate the loopback. Chart 12 is a diagram of the steps that occur to operate the loopback.

Chart 12. Maintain demand-action loopback

Step 1.

The SM sends an MSG_A_ACTION S_RM_RTU OP_TEST_LOOP message with the term_pt_cond feature to request DS1 loopback.

Step 2.

The RM responds with an MSG_ACK S_RM_RTU OP_TEST_LOOP receipt notification message indicating to the SM that the request has been executed and two-way loopback has been enabled.

See chart 13 for loopback release.

Chart 13. Demand-Release Loopbacks

Step 1.

The SM sends an MSG_A_ACTION S_RM_RTU OP_TEST_UNLOOP message with the term_pt_cond attribute to release the DS1 loopback.

Step 2.

The RM responds with an MSG_ACK S_RM_RTU OP_TEST_UNLOOP receive notification message indicating that the release has been performed and the two-way loopback has been removed. The SM may also require an RM to perform module self test. See Chart 14.

Chart 14. Maintain Demand-Performance Self Test

Step 1.

The command to perform a self test to the RM is controlled by the SM sending a MSG_A_ACTION S_RM_DIAG OP_DUMMY message to the RM.

Step 2.

The RM receiving the self test capability message responds with an MSG_ACK S_RM_DIAGOP_DUMMY receipt notification message indicating to the SM that the message was received without error but the message was not fully processed.

Step 3.

If the RM has processed and executed the self test capability command, the RM sends an MSG_ACK S_RM_DIAG OP_DUMMY message to inform the SM that the self test command has completed. Returning the rm_eqpt_cond attribute provides the result of the self test.

Software upgrade

LAS has the ability to upgrade software. This indicates that the SM can send new executable code to the RM via a message channel, or via a time slot, as shown in chart 15. The section describes a process for sending executable code over the message channel.

Chart 15. Software Downloads

Step 1.

The SM sends a MSG_A_ACTION S_RM_SWOP_SW_RM message with new software as payload.

Step 2.

When the RM receives, confirms and stores a segment of the new software, the RM sends an MSG_ACK S_RM_SW OP_SW_RM acknowledgment message informing the SM that the segment has been processed. The sequence is repeated until the last segment is ready for transmission.

Step 3.

The final segment of the software will be an MSG_A_ACTION S_RM_SW OP_SW_RM_FINAL message indicating to the RM that this is the last segment.

Step 4.

When the RM receives, confirms and stores the segment, the RM sends a MSG_ACK S_RM_SW OP_SW_RM_FINAL receipt notification message to inform the SM that the segment has been processed.

The messages described in the section above align the message receipt notification status with "in progress" or "OK". If the message is sent with an error, there will be a different reporting state. This section will provide details of the optional receive notification status.

A module receiving a request that cannot be executed due to other parameter settings in the module notifies the receipt of the original message with a "failure" status. The module that initiates the original message then tries to resend the message twice before declaring a failure. This failure state has the highest priority because incorrect crc calculations in a message can cause other failure states.

A module that receives a request to modify a variable that does not change returns a "read-only" state in the receipt notification message. The initiating module then logs the response and does not attempt to resend the message.

A module receiving a request to modify a variable with an out-of-range value returns a status of "Insufficient Value" in the receipt notification message. The initiating module logs on the response and does not attempt to resend the message.

A module receiving an invalid message type returns a "unknown message" status in the receipt notification message. The initiating module logs on the response and does not attempt to resend the message.

A module receiving an invalid message type returns a "bad subtype" status in the receipt notification message. The initiating module logs in the response and does not attempt to resend the message.

Receiving a software download segment number that has failed or has lost a segment, the RM responds with a "bad segment" status in the receipt notification message. The SM then retransmits the first segment after the last known enough segment transmission.

The following table describes an organized list of message channel messages.

Table 17

Shelf Manager Initiated Message

Table 18

Resource Module Initiated Message

Clock synchronization

As noted, the modules of the LAS 14 may be classified as shelf managers SM 21 or resource modules RM 10. SM type modules have the ability to master the system bus. An RM type module may have the ability to recover timing synchronization information from a remote location or may require the ability to synchronize transmissions using an external source.

The LAS clock interface (FIG. 47; 1400) performs two functions. The first function of the clock interface is to provide a mechanism for the transfer of TDM data between modules of the LAS shelf. The second function is to maintain synchronization between the wireless communication service and the wireless communication service deployed from the LAS 14. There are two clock interface elements. One element is responsible for mastering the timing for the entire system. The other element serves to provide an information signal to the master for network synchronization. As shown in FIG. 47, the clock electronics are divided into two regions. The top part provides an 8KHz timing reference for network synchronization. The bottom part provides system timing for the transmission of TDM data on the back panel. The bottom locked loop (PLL) 1420 at the bottom of the figure provides a 16.384 MHz system backplane clock 408 and an 8 KHz framing pulse 406. The system clock is divided into four buffered clocks 402 for distribution on the backplane as shown by the four outputs SCLKX2N_1 through SCLKX2N_4. Each clock signal is provided to one of four resource module (RM) segments of the system. The bus switch provides a means for isolating the driving signal from the system backplane where multiple modules with timing master interfaces are present when inserted into the functional system or as shown. The interface design can act as a timing slave when another master is provided as indicated by the CLKFAIL signal 1404.

The top of FIG. 47 shows the interface for network synchronization. Three modes of timing operation are provided: loop timing, office timing and internal timing are used. Loop timing is provided by the recovered 8KHz clock signal generated from the RM included in the system. The RM should have the ability to recover timing information from the loop. Not all RM types have this capability. The LAS backplane provides three independent sources of recovered 8KHz clock 410 that can be used as loop timing synchronized sources. In the office timing mode, the timing master uses an interface from the central station (BITS clock) to the synthesized clock (CC). A second interface to the composite clock source 416 may be provided to the redundant CC source. In situations where an office timing and loop timing source is not provided, an internally generated timing source may be provided from the Stratum 4 oscillator 1414. Each 8KHz timing reference described above may be assigned by switch 1418 as a first, second or third source to maintain clock density in the event of a source failure. The quality of the clock source is monitored by logic (not shown) to detect failure.

Office Sync (Figure 48)

The timing master provides an interface to the composite clock provided by the central office (BITS). This timing source is a bipolar signal (Figure 48A) consisting of 8 and 64 KHz timing information. The timing master ensures the relationship between FSYNC (Figure 48B) and the office clock. The timing slave, RM, guarantees the relationship between the byte (Figure 48C) and the bit (8 & 64KHz) clock as shown. This timing relationship eliminates the need for transferring byte and bit clocks on the backplane.

Recovered Clock Supply (Figure 49)

Each RM 10 with the ability to recover timing information from the communication loop interface implements the circuit shown in FIG. The RM provides a means for supplying one recovered clock from any loop timing source 1432 to any three backplane interface signals 1430. Three backplane signals 1430 are used by the system as the first P, second S, and third T sources of loop timing.

Slave Operation (Figure 50)

An RM 10 that does not have the ability to master system timing as described above must recover timing information from the backplane as shown in FIGS. 50 and 51. In this type of module, the TDM interface 1450 requires local generation of the clock signal called SCLK. The module also requires 8 and 64 KHz clocks 1451 and 1452 for the DS0 type interface as shown in FIGS. 50 and 51.

Clock handoff

The timing interface allows two modules in the system to master timing. Only one module can be a timing master at a given time, and only the cards in slots 25 & 26 have the ability to provide the necessary timing signals to other RMs. A standard TDM framing cycle is shown in FIG. 52. Data is transmitted in bit serial mode and framed by the FSYNC signal. This pattern allows 128-bit information to be transmitted by the backplane. Under normal conditions, the CLKFAIL line is always driven low by the activation master. All potential timing masters make these signals high. Lack of drive by the current master generates a high state and indicates a failure. The failure condition will trigger an uncontrolled handoff with an enhanced mast. This type of transmission results in a short time loss of service where no timing information exists until a new master takes control. The CLKFAIL signal is also used to synchronize the transmission of timing master rights to other masters in a controlled manner as shown in FIG. As shown, the adjusted handoff causes the CLKFAIL signal to be driven high during the low portion of the FSYNC pulse. Immediately thereafter, the current master “parks” the output clock signal in a high state and then transmits in a high impedance state. This allows the alternative master to start the next TDM frame cycle in the correct sequence without interrupting service.

Shelf Manager Timing

To illustrate the timing and clock synchronization capabilities implemented in the Shelf Manager.

Timing signal input

Synthetic Clock Input

The SM recovers the composite clock synchronization signal supplied externally to the system. The synthesized clock is a synchronization signal that is a 64 kbps, 5/8 duty cycle, all-ones, bipolar zero value return signal with a bipolar violation every eighth pulse. The input synthesized clock preferably meets the requirements of Bellcore TA-TSY-000378 and ANSI T1.101. In particular, the SM recovers the first synthesized clock synchronization signal externally supplied to the system. The second synthesized clock source can be used as a latent clock replacement system upon failure detection of the first synthesized clock source whose timing mode is office timing.

Restored 8KHz Clock Input

The SM has the ability to select from three independently restored 8KHz clock synchronization sources. This recovered 8KHZ clock source is provided by an RM with the ability to recover timing from a remote source. These clock sources are available from the system backplane and meet the requirements of standard TTL level signals. The recovered 8KHz backplane signal is sensitive to reflections that can cause false triggering if used as a clock signal. Incident waveform transmissions represent actual timing reference points. The next transmission that can occur within 100nS time is ignored.

Clock fail signal input

The SM has the ability to monitor the status of the CLKFAIL backplane signal. This input is used to detect the absence of a system bus master and is used as a trigger to initiate a controlled system bus master handoff from the current master to an enhanced redundant master.

Timing signal output

The frame sync output is provided as FSYNC on the system backplane. The output can be synchronized to an enabled timing synchronization source input signal. The system clock output is provided as SCLKX2N_n (n = 1 to 4) on the system backplane. The output can be synchronized to an enabled timing synchronization source input signal. The SM has the ability to drive logic low on the CLKFAIL backplane signal. The CLKFAIL output is used to signal the presence of a system bus master or as a trigger to start a controlled system bus master from the current master to an enhanced redundant master.

Clock Monitoring (Figure 47)

Each timing synchronization source includes circuitry 1460 that can monitor the state of the source. The circuit is sufficient to detect clock corruption and enables management of the clock recovery process.

Timing mode

The user has the ability to select the next timing mode for system synchronization of the aforementioned outputs. The choice of timing synchronization mode is determined by selection by the operator interface or any possible motion support system interface. In office timing mode, the primary system synchronization source is due to the composite clock input signal supplied externally to the system. The SM provides a clock recoverable RM to provide a recovered clock source for each recovered clock input. In internal timing mode, the main system synchronization source is due to locally generated timing sources. The internal timing source preferably meets the Stratum 4 requirements specified in TA-NWT-1244, Section 3.

Clock Holdover Timing

Clock holdover is defined as the ability to maintain the phase and frequency relationship of the output clock with respect to the timing reference in the absence of a timing reference. The holdover state allows the system timing relationship to be maintained for a temporary period until an alternate timing source is supplied or the current timing source is restored.

Without a readily available alternative source, the loss of the current timing source causes an input into the clock holdover state within 100mS. The input to the holdover causes a change of approximately 500 nsec in the time delay between the leading edge of the holdover timing signal and the DS0 output data. During the first 15 seconds holdover, it is preferably a phase-time shift on the start clock of approximately 500 nsec. If the external CC reference is restored within the time when the DS0 data is still phase aligned, the recovery will preferably cause an error of approximately one second. If the external CC reference is restored prior to the time when the DS0 data is no longer phase aligned, the resave of the DS0 physical layer phase aligned to the external synthesized clock signal will preferably issue within one second.

Sync option selected by the user

The user always has the ability to select the first synchronization source from the timing mode described above. The user can select a second synchronization source from a timing mode that omits the office timing source. The selection of the second source is possible only after the selection of the first source. The user can select a third ventilation source from a timing mode that omits the office timing source. The selection of the third source is possible only after the selection of the second source.

Clock Replacement System and Inversion

The clock replacement system is an automatic switching from a user selected synchronization timing source to an alternative selection timing source upon detection of a clock fault. Clock inversion is defined as the ability of a failed timing synchronization source to be stored as a source upon signal recovery.

The alternative system plan includes three synchronizable sources designated as first, second and third. The internally generated fourth source can always be used. The fourth synchronization source includes a synchronization source table. The clock replacement system is accomplished in a round-robin fashion. Round-robin is defined as an inversion relative to the top of the synchronization source table and only occurs when the table's timing synchronization source set is empty. The current alternate system state and synchronization source can be obtained from the user interface. Source status (damaged or undamaged) may also be used for each user selected source. The rate of phase change of the clock signal switching the synchronization source is limited in accordance with TA-NWT-1244.

The status table of FIG. 54 applies when the current synchronization source is damaged. Switching occurs within 100 milliseconds from when damage is detected. The synchronization source is declared corrupted by the detection of a signal loss (LOS) condition or by the detection of a fractional frequency offset exceeding 1.1x (Long Accuracy + Pull-in Range). For Stratum 4, this is a 0.5632 Hz offset based on 1.1x (32x10-6 + 32x10-6) = 70.4PPM or 8KHz. Signal loss is defined as one or more missing clock pulses. The LOS state no longer exists when the correct clock is received for at least 1 millisecond. The composite clock CC is declared damaged by detecting the above criteria in addition to the degree of inaccurate bipolar violations deviating from one of the eight patterns.

The state diagram of FIG. 54 applies at the time of recovery of a previously corrupted synchronization source. The inversion from holdover to standard mode when the timing office is allowed allows for detection of a valid composite clock of at least 10 seconds.

Clock handoff

Clock handoff is the switching of system bus master rights and system timing synchronization from the current (active) master to an alternate master. The SM, acting as the active bus master, is indicated by the front illuminated “in service” LED. Only one such unit will be in the “in service” state at any given time. An SM in "not in service" state can be removed from the shelf without causing any system error. Uncontrolled handoff can cause unplanned failure or removal of an active bus master. The removal of the SM acting as an active bus master without managing and placing it in the "not in service" state allows the bus master rights to be transferred to the alternative bus master. Preferably approximately one second, which is an error on any DS0, occurs due to the transmission. Removal of an activation master without an alternative master causes a system failure of the service. Controlled handoff is the deliberate handoff of bus master rights from an activation master to an alternative master by a user driven command. The SM, acting as an active bus master, transfers bus and timing master rights to alternative units when commanded from the operator interface to a "not in service" state. The action causes the alternative unit to be placed in a "in service" state. The SM, acting as an alternate bus master, transfers bus and master rights from the activation unit when commanded from the operator interface to the "in service" state. The action causes the activation unit to be placed in a "not in service" state. The command causing the clock handoff is prohibited if no alternative SM is provided or the bus master function cannot be performed. The user is preferably informed to the instance. The transition to the alternate bus master causes some clock aberration. In the worst case, approximately 1 second of error in DS0 interfaces the result.

Timing quality

The SM preferably conforms to the timing synchronization requirements specified in the equipment using the DS0 interface. These requirements are shown in Table 38. The leading edge of the DS0 output signal has the same meaning as the leading edge of the 8KHz FSYNCN output signal when the unit stay condition is analyzed.

Table 38

Timing Synchronization Requirements

Requirements Specifications Remarks Phase alignment 0 -1 milliseconds Time delay between the leading edge of the composite clock input signal and the leading edge of the DS0 output signal Wander <100 ns For low frequency jitter (wander) while reaching 10 Hz on the composite clock leading edge, the DS0 output signal leading edge will be tracked within a certain number. Phase hit 500 ns pk -pk With a rate of change of up to 1.326 ms and up to 81 ns, and during phase hits at up to 1 ms of composite clock input, the DS0 output leading edge will track the composite clock input reading within a specific number.

The unit will preferably meet the Stratum 3 accuracy, stability and pull in range requirements specified in TA-NWT-001244. The above and composite clock phase alignment objects are shown in Table 39.

Table 39

Timing synchronization object

Requirements Specifications Remarks Accuracy 4.6 ppm Long time deviation from standard frequency without external reference Phase alignment 250 ± 50ns Time delay between the leading edge of the composite clock input signal and the leading edge of the DS0 output signal Stability ± 3.7 × 10-7 per day for the first 24 hours Rate of change of frequency from input frequency when external reference is removed [20 × 10-9 (initial) + 355 × 10-9 (due to temperature) + 10x10-9 (others) Stability with factored temperature components Wander generation Second 5.3 TA-NWT-1244 Wanderer transmission Ultra 5.4 TA-NWT-1244 Create Watter Seconds 5.5 TA-NWT-1244

Clock-related alarms

Minor alerts are declared when the detection of a partial frequency offset (accuracy + pull-in range) of 1.1x or one or more reference source losses (eg, a mixed clock in a timing office or a first synthesized clock in a timing loop), For Stratum 4, this would be 1.1x (32x10-6 + 32x10-6) = 70.4 PPM or 5,632 Hz offset at Stratum 4 at 8 KHz. A major alarm is declared if the minor clock alarm condition is maintained for 24 hours or if all reference sources lose their replacement system for internal timing.

Resource module timing

The timing and clock synchronization function specified in the resource module is described.

Timing signal input

The frame synchronization input signal is provided as FSYNC on the system backplane. This input is synchronized with the enabled timing synchronization source signal provided by the SM. The system clock input signal is provided as SCLKX2N_n (n = 1 to 4) on the system backplane that depends on the specific slot address occupied by the RM. The local version of this signal is labeled SCLKX2N. The input is synchronized with the enabled timing synchronization source signal provided by the SM. The input is used to detect the absence of a system bus master or as a trigger to initiate a controlled system bus master handoff from the current master to an enhanced redundant master.

Timing signal output

The RM can recover 8KHz timing synchronization information from a remote source. The RM can use the recovered clock source to drive the REC8KHZ_P, REC8KHZ_S, and REC8KHZ_T output backplane signals when providing commands from the SM. RM provides high impedance on each signal. When the RM contains several recovered sources, a particular source can also be selected by providing commands from the SM.

External synchronization and timing recovery

For RMs that require DS0 synchronization and timing information, the 8KHz byte clock recovery signal is regenerated by using the SLCKX2N and FSYNCN timing signals. The two input timing sources are synchronized to an external synthesized clock source by the SM. The 64KHz bit clock recovery signal is regenerated by using the SCLKX2N and FSYNCY timing signals. The two input timing sources are synchronized to an external synthesized clock source by the SM.

Circuit card hot-swap system for LAS

The hot-swap system allows the resource module (Rms 10) of the LSA 14 to be inserted and removed from the system without error or interrupting services provided by other modules of the system. The hot-swap system comprises three elements; It is divided into electric, mechanical and software.

Electrical elements (FIGS. 55 and 56)

The electrical element includes circuitry that serves to detect the time division multiplexing (TDM) bus 42 of the LAS 14 used for route communication data between modules. Detection of the bus is essential for error free operation of other modules of the system. The two circuit elements are known as 'inrush currnet limiters' 606 and 'bus isolation' circuits 600. A diagram of the bus isolation circuit is known from FIG. 55.

The electrical element also includes circuitry to limit in-rush current upon module insertion. This protects the first power distribution system from interruptions that can interface with proper module operation. A block diagram of the in-rush circuit is shown in FIG.

RM bus isolation

Each RM 10 includes a mechanism that allows the shelf manager (SM) 21 to isolate the malfunctioning RM from the backplane 42. The insertion or removal of an RM does not cause a transmission error on a timeslot in use by another card due to the bus isolation mechanism. Bus isolation mechanisms include free charge voltage, isolation module, start request, bus enabling, and the following normal tests: free charge voltage and isolation module.

The A + 5V free charge available in all slots of the LAS can be used to provide an early make / late break connection of + 5V to power the bus isolation module 600. The module includes a high speed CMOS bus switch 602 designed to provide hot swap capability. The device is designed to allow power up in high impedance conditions. This isolates the module backplane from any TDM bused signal, clock and message channels. The bus isolation module is controlled by the addressable switch 602, which is then under the control of the SM 21. The addressable switch is powered up, so the I / O is forbidden and remains until addressed and commanded by the SM.

Bus switch

Bus switch 602 is designed to be essentially high impedance when the circuit card has no power or is actively disabled. The Dallas switch DS2405 or DS2407 is controlled by the backplane signal CNTLi, enabling or disabling the message channel from the backplane. Dallas switches provide circuit cards with unique serial numbers.

The DS2405 device provides one switch that controls the operation of the message channel isolation switch. The optional DS2407 device provides two switches, the second of which is used to disable the onboard power converter and removes the circuit card load from the main power bus. When the Dallas switch is disabled, the TDM bus 42 is disconnected from the backplane. When the Dallas switch is enabled, the TDM bus and clock switch are controlled by the onboard microcontroller 604.

Initialization request

Upon insertion, the RM 10 requires initialization by making the CNTLi (i = 1 to 25) read high. 57 shows a timing diagram for an initialization request. The lead is used to signal the SM into which the module is inserted. The SM responds by sending a request pulse on the CNTLi. The addressable switch 602 on the module responds by sending a pulse. Once a pulse is detected, the SM queries the addressable switch for the factory assigned a unique address and then requires the RM to report the result of the power on shelf test (POST). If the result is satisfactory, the SM enables the RM backplane I / O. This will place the bus isolation module 600 in a transparent state. The module allows the shelf manager to communicate on the backplane when it asks the module's addressable switch using CNTLi. A "breakdown protocol" is used for this request.

The question of the unique address consists of distributing an 8-bit read ROM (0x33) instruction to an addressable switch on the module. The CNTLi read integrates a standard Dallas semiconductor disconnection protocol for data transfer, with all data being read and written to the least significant bit first. The module's addressable switch responds with the contents of a 64-bit ROM according to the following format.

MSB LSB MSB LSB MSB LSB 8 bit CRC code 48-bit serial number 8-bit family code (0 × 05)

Once the SM has determined the correct 64-bit ROM of the target switch, it will send an 8-bit match ROM (0x05) command followed by the 64-bit ROM sequence. This allows the addressable switch to toggle I / O control ON.

Sanity test

There is a possibility that after an RM is in service, a malfunction can affect other modules by causing an error on the bus. To minimize the impact that the module can have, the CNTLi reads will pulse low within 600 ms for 100 ms. The SM considers the presence of a watchdong pulse within a 600 ms window as an indication of a malfunctioning unit. The SM causes the malfunctioning module to be disabled by pulling and holding the CNTLi leads low (minimum 480ms). This effectively removes power from the addressable switch 602 to return the I / O control to the default OFF.

After the malfunctioning module is isolated from the bus, the SM emits CNTLi leads (for every 200 ms) periodically (every 500 ms) to determine if the module has been physically removed from the slot. Emitting the CNTLi lead at this point does not affect module access to the backplane because the I / O remains OFF. If the module has been removed, the SM will watch for insertion of a new module. If the module has not been removed, the SM will continue to watch for removal of the module.

Optionally, modules actively connected to the backplane can be physically removed. When it detects that the CNTLi lead is no longer pulled high (at least 480 ms), the SM interprets this as module removal and looks at whether the CNTLi is pulled high when another module is inserted into the slot. RM provides the supervisor function on the CNTLi lead by pulling the line low within every 600ms for 100ms. RM puts the backplane I / O in tristate if the CNTLi lead is held low while> 480 ms.

In addition to providing a watcher function for the CNTLi read, the RM periodically sends a "keepalive" message. The watcher function provides a low level indication of the RM status that can be transmitted and monitored with a relatively high frequency, reducing the time that common resources are exposed to RM failures. Keepalive messages are a more extensive way of identifying states and states of RMs, but they provide a way to maintain message channel bandwidth with much lower frequencies.

Mechanical element (Fig. 58-61)

The mechanical element of hot-swap technology consists of guide pins that align the plugs of the module and ensure that the electrical ground connection is established prior to any other electrical circuit connection. The guide pin consists of a male pin 630 on the backplate connector 632 that matches the female pin socket 634 in the plug of the module. Backplane guide pin 630 is shown in FIG. 58.

Software element

The software element of hot-swap technology ensures detection of the backplane TDM bus upon module insertion or failure. The detailed description of the backplane access protocol has been described previously with the description of the disconnection protocol and the message channel.

2DSL

The following describes an embodiment of an SDSL resource module with two SDSL line interfaces. The 2SDSL module is a resource module 10 of the LAS 14 (Fig. 6) for use in the transmission of 2B1Q formatted data at rates corresponding to 4,6,8,10,12,18,24,30,32 and 36 DS0. )to be. This ratio can be configured via an operator interface hosted on the shelf manager unit 21. It also includes a 16kbps framing channel that supports an embedded operating command (EOC) channel.

Main Applications for 2SDSL Modules As described in the next section, we will be using an access device integrated with a backplane extension. Also described is signal operation and transmission of data circuits and POTS via 2SDSL RMs.

60 illustrates an integrated access device (IAD) application. In this application, the 2SDSL module 820 is used to provide cheap return shipments for the customer's LAN and POTS voice services in the area 824 to the networks 9810 and 812 via the SDSL line 821. The figure displays IADs 822A, 822B connected to a single 2SDSL resource module.

In the backplane extension application as shown in FIG. 61, the LAS shelves 12 are connected together in the "daisy chain" manner of all connected frames--basically in the connecting backplane. In other applications, the 2SDSL module can be used for POTS aggregation and transmission of frame relay data for the GR-303.

The 2SDSL RM may be configured to support different types of payload timeslot structures for communication using IAD over SDSL lines in 36-DS0 frames:

IAD frame data with voice

IAD frame data without speech

Empty channel data frame

IAD frames support CPE 822A, 822B (FIG. 60). The empty channel frame is designed to support a connection between two shelves (Figure 61). 62A-62C display three payload timeslot structures. Signal DS0 832 sends voice signal information for POTS channel 834 to IAD or from IAD, and reserved DS0 830 supports OAM & P for any data channel 836 connected to IAD. . In shelf-to-shelf configurations, neither reserved or signal DS0 channels are required and an "empty" digital channel with 36DS0 may be provided.

For communication between the 2SDSL resource module 820 and the IAD 822, the transmission mechanism is one of the above combinations of PCM, ATM, High Level Data Protocol (HDLC), Point-to-Point Protocol (PPP), Frame Relay, or TDM architecture. Can be. The data type is transmitted in burst packetized data from real time voice.

IAD 822A (FIG. 60) includes a four-port Ethernet hub supporting 4 POTS ports and TCP / IP in addition to several routing functions. The transmission is a TDM for both voice using PCM and voice with data using HDLC encapsulation or PPP and data (FIG. 62A). In one embodiment, four POTS interfaces provided to IAD 822A are managed by SM 21 (FIG. 6). Once the SDSL transmission path is in service, the POTS channel can be serviced.

IAD 822A is responsible for analog line signals and instructions in addition to digital signal bit input / extraction. The POTS interface may be provided as a universal voice class or as a single party "channel unit." State management (ON-HOOK and OFF-HOOK) is performed in the IAD and passed to the 2SDSL RM. Next, RM provides proxy POTS function, forwards SM's commands on IAD to IAD, and forwards IAD's instructions to SM. However, the original signal passes through transparently.

The voice signal passes through a dedicated DS0 832 (Figure 62A) with nearly 24 channels multiplexed in the upstream and downstream directions, with provision for expansion in advance of 30 channels per DS0. In terms of downstream, the logic of the 2SDSL 820 enables discrete output settings upon monitoring and detection of various signal bit patterns. In terms of upstream, the logic enables several signal bit patterns corresponding to the detection of discrete input states. Signal bit interpretation may be provided as one of D4 (superstream), TR08, ESF or GR303 for each line interface.

Trunk conditions occurring in band for voice / signal DS0 are handled in IAD 822A. The trunk state starting within the shelf (due to the SM command) is activated by the SDSL RM with the appropriate tone inserted and by the appropriate analog signal state determined by the SDSL RM and delivered to the IAD 822A via the EOC.

The data interface is provided through the remaining DS0, reserved or unused for signal / voice, and will vary in bandwidth depending on the line rate. The 2SDSL RM provides a transparent data path to the allocated data DS0. Once the SDSL transmission path is in service, the data interface can be serviced.

The data and / or voice service may include ATM, data using AAL5, voice using AAL1 circuit emulation service (CES) with channel assigned signal (CAS) (ANSI / TIA / EIA-464-B) for signals. For CES v2.0).

Next, the execution of the EOC is initiated, which complies with TS 101 135 and T1E1.4 / 96-006, includes framing, bit / byte allocation, and the standard set of messages is HTU-C (HDSL Terminal Unit-Central Office) Thereby enabling the reading / writing of any logic 'register' of the HTU-R (HDSL Terminal Unit-Remote). For such applications, the standard EOC protocol is considered reliable enough to eliminate the need for high-layer error detection / correction.

In the following sentence, the terms upstream and downstream are used. Downstream for 2SDSL depends on whether it is HTU-C or HTU-R. As HTU-C, downstream is directed towards the SDSL interface and as HTU-R to the backplane. Upstream is in the opposite direction. This means that the IAD is always used in HTU-0R mode, so downstream is directed to the customer (Ethernet) and upstream is directed to the network (SDSL).

The EOC is used to apply trunk status (TC) by commanding the opposite end. To enter this correctly, an overview of TC, alarm and service status will be helpful. In FIG. 63, a TC is associated with data and / or signal patterns used to overwrite a voice or data channel when a channel is out of service when an alert condition is detected or when the TC is activated by an SM.

For the HTU-C RM 820A, the trigger for the TC is as follows.

SM command

Loss of signal / sync on SDSL line

HTU-R alarm indication ("local data interface OOS")

For the HTU-R RM820B, the TC trigger is

EOC order

Loss of signal / sync on SDSL line

SM command

If the HTU-R is an IAD 822, the TC trigger is as follows.

EOC order

Loss of signal / sync on SDSL line

Signal / loss triggers affect all channels provided by the HTU, while other triggers are assigned to specific cross connections / channels.

The HTU-C receives the TC's TC and Insert Word (IW) values at the time of the cross connection for use when the TC is activated on the cross connection. Due to the limitations of the IAD 822, the supplied TC value is ignored and a hard coded TC occurs at the IAD, where the TC is instructed to be activated. The supplied TC value is ignored and hard-coded TC is applied in the upstream direction. HTU-C does not perform any TC in the downstream direction. HTU0C monitors the states that require TC activity. The difference between actions occurring in the voice and data interfaces can only be applied to HTU-C, which is an empty channel mode in IAD mode.

Upon detection of a TC trigger on the voice interface cross connection, the HTU-C sends a TC activation command corresponding to the voice interface at the HTU-R via the EOC. When the TC trigger no longer exists, the HTU-C sends a TC Deactivate command for the corresponding voice interface at the HTU-R via the EOC. If the HTU-C detects a TC trigger on a cross connection of the data interface, it sends a TC activation command for the data interface at the HTU-R via the EOC. It also transmits everything in the HTU-R direction through all affected DS0.

HTU-C monitors for conditions that require upstream TCs. Standard event reporting to the SM is performed continuously. If a TC trigger is detected, the HTU-C sends everything in the upstream direction at the affected cross link.

When the TC at a given voice interface is active, ringing is stopped and silence is transmitted on the line, as if connected to the line Quiet end. When the TC on the data interface is active, any data received from the SDSL link is ignored and no data is sent downstream. If the HTU-R is an IAD, no Ethernet frame is generated. If the HTU-R is a 2SDSL RM, everything is transmitted in all affected timeslots.

When the TC on a given voice interface is active, the upstream TC in the IAD consists of transmitting the silence of the channel and the appropriate "on hook" signal bit pattern upstream. In the HTU-R RM, the upstream TC consists of transmitting all the upstream of the affected DS0. If TC is on, the data interface is cross-connected. The HTU-R RM sends everything upstream through all affected DS0s, and the IAD does not send any frames upstream. When the TC is active on the data interface, the HTU-R sets the "local data interface OOS" in the HTU-R status register, which is empty when the TC is inactive.

The functionality of the 2SDSL RM 820 has been described at the system level and modules will now be described with reference to FIG.

The module is software to operate at one of 256K, 384K, 512K, 768K, 1152K, 1536K, 1920K, 2048K, or 2304K bit rates per second resulting in transmission of 4,6,8,12,24,30,32 or 36 DS0 timeslots. Can be provided. Data passing through the DSL 821 (FIG. 60) is coupled from the line via the line interface 850. Line interfaces include hybrids, filters, HDSL transformers, thunder protection, sealing currents and metallic test access.

From the line interface, data passes through the channel unit 854 and the transceiver 852 that are responsible for data processing in accordance with the HDSL standard. The FPGAs 865A, 865B pass data to the universal timeslot interchanger (CT812; 858), the bus switch 860, and the backplane of the system. The message channel 30 is used to pass messages to and from the SM 21 via the bus switch, CT 812 and HDLC controller 862.

The transceiver (bit-pump) 852 has a built-in frequency synthesizer that enables variable rate configurations (144 kbps to 2320 kbps). The synthesizer uses a single 10.24MHz crystal as a reference. The receiver performs remote unit clock recovery by an on-chip phase locked loop (PLL) circuit. The device also manages initiation and performance monitoring operations.

In the receive direction, data is received from the DSL link and passed to the internal digital signal processor (DSP) of the transceiver 852 which is responsible for extracting the other end of the 2B1Q encoded signal. The output of the transceiver is sent to channel unit 854 on the RDAT, BCLK, and QCLK lines. RDAT outputs a series of quarternary data, BCLK is a bit rate (double symbol rate) clock output, and QCLK operates at symbol rate.

In the transmission direction, digital symbols arrive from channel unit 854 on the TDAT input and are transmitted in analog signals. The analog signal is set to minimize crosstalk to adjacent subscriber lines. This setup allows the output signal to meet the standard requirements for pulse shape, power spectral density, and output power at 784 kbps, 1168 kbps, and 2320 kbps, without any change being required for external devices including line transformers. . Symbols are optionally scrambled. Isolated pulses can also be generated to support testing of the pulse template.

Channel unit 854 is divided into two sections: PCM section 854A and HDSL section 854B. The PCM section is connected to CT812 858 (FPGA 856A) and the HDSL section is connected to transceiver 852.

The PCM section controls the flow of data between the PCM and HDSL sections, sets the alignment between the PCM and HDSL frames, and maintains synchronization between the PCM and HDSL clocks. PCM serial data is a framed data signal consisting of 64 8-bit timeslots. The PCM timebase generates a 6 ms frame time based on the transmit clock TCLK and receive clock RCLK. The PCM timebase is programmed to be approximately equal to the HDSL 6ms frame time associated with the bit clock BCLKn of the HDSL section. The final PCM and HDSL 6ms frame interval sets the alignment between PCM and HDSL frames, maintains synchronization between transmit clocks by performing bit stuffing, and recovers the PCM receive clock by comparing the phase offset between frames. To be used.

The HDSL section includes the following: sampling and alignment of input signal and magnitude data (see Table 40), scrambling / descrambling of payload data, error performance monitoring, and HDSL data from received HDSL frames. Payload mapping from the transmitting PCM frame to the HDSL frame, assembly of the HDSL output frame, and disassembly of the HDSL receive frame.

Each HDSL frame is nominally 6ms long and consists of 48 payload blocks, each of which consists of a single Z-bit plus 36 payload bytes. A group of twelve payload blocks are separated by a concatenated and aligned set of HDSL overhead bits, with a 14-bit SYNC word pattern identifying the starting position of the HDSL frame. Although 50 overhead bits are defined in the HDSL frame, the last 4 STUFF (sq1-sq4) bits are nominally present in other frames. Thus, one frame contains 48 overhead bits on average.

Table 40

2BIQ symbol coding

In the receive direction, channel unit 854 obtains a serial data stream on the RDAT1 input sampled at the downside of BCLK1. Serially encoded 2B1Q sign bits are sampled when QCLK1 is low, and 2B1Q size bits are sampled when QCLK1 is high.

BCLK1 operates at twice the speed of 2B1Q (QCLK1 speed). The down section samples the QCLK1 and RDAT1 inputs. In the transmission direction, the rising part of BLCK1 outputs transmission data in TDAT1.

The FPGA 856A and 856B support the following on both channels:

1. Data, clock and synchronous transfer to channel unit 854 between CT812 858.

2. Convert the downstream frame to IAD signal frame format (see FIGS. 62A-62C).

3. Synchronize the received signal with local clock and sync using elastic memory.

4. Provide access to FPGA revision number and slot ID via blocks 880,878.

5. Provides access to 30 voice-connected upstream signal data.

6. Control / monitoring of bus and ID switches 860,861 through blocks 872,874,876.

7. 'sealing current' and 'metal test connection' relay control via block 886.

8. LED control via block 884.

9. Interrupt handling via blocks 890,892.

65 shows data, clock and synchronization flows between CT812 858, FPGA856A, 856B, and CU854.

In the downstream direction, the FPGA obtains data and voice information for channel # 1 from the SO_0 output of the CT812 and the signal information from SO_4. Data and voice information for channel # 2 are received from the SO_1 output of CT812 and signal information from SO_5. The data rate of each of the SO outputs is 4.098Mhz, or 64 timeslots of DS0.

Channel units receive on the TSER circuits a 4.098 Mhz data stream carrying data, voice and signal information (if IAD mode is selected) as shown in Figures 62A-62C.

When the IAD mode without POTS is selected, that is, in FIG. 62B, the PCM frame does not transmit a signal time slot and the voice / data time slot starts at time slot # 2. When the clear channel mode is selected, i.e., for FIG. 62C, the frame carries neither preliminary or signal timeslots and the voice / data timeslot will begin at timeslot # 1.

The FPGA acquires local clock and local frame synchronization and sends these signals to the channel units.

In the upstream direction, the FPGA obtains data, voice and signal from the RSERs in the RSER (in the same format as presented above). The FPGA obtains RCLK and RMSYNC signals from the CU. These signals are used by elastic memory (shown below). The FPGA transmits the reception information from the CU # 1 to the SI_1 of the CT812 and transmits the received information from the received information CU # 2 to the SI_1 of the CT812.

As further presented here, the FPGA provides a signal frame format conversion referred to as a "swizzler" function. This swizzler block 857 converts the downstream signal frame structure sent by CT812 to the different signal frame structure used by the IAD (CPE). The difference between the structures is in the order in which the signal bits are arranged in the frame. For example, the following four voice cross-connects can be established for downstream transmission to the IAD.

In this case, the Swizzler function rearranges the signal bits and the first signal timeslot corresponding to signal DS0 832 (FIG. 62A) is as follows:

Data received from the channel units is passed through the elastic memory device to compensate for the phase shift between the backplane bus and the SDSL. Data from the HDSL to the system backplane is synchronized to the CT812 timing control. Data transferred on the DSL is passed through the FPGA without elastic storage.

Upstream signal portion 859 of FPGA 856A is shown in FIG. This block searches for valid signal timeslots in the upstream direction and then extracts the appropriate A, B, C, D signal bits from all 30 possible far end POTS connections. Signal information for the 30 POTS is transmitted in the second timeslot portion of the HDSL upstream frame as mentioned previously. To obtain all the signal information of this 30 POTS, the signal block 859 processes the signal timeslot 832 (FIG. 62A) of 24 consecutive DSL frames.

Referring again to Figure 66, the 'Signal T.S Extract' block 894 identifies the signal timeslot (Figure 62A). The extracted timeslot is sent to 'signal framer' 899, which checks the phase P1 and P2 bit sequences. If the state machine identifies a valid phase bit sequence in six consecutive frames, this block displays a 'valid signal T.S' and a 'non-valid signal' if one of the frames is included in the valid phase bits. do.

The 'signal register bank' block 898 has a current signal of all 30 POTS per channel. If all registers contain valid information, this block passes a 'valid' indication to the 'CPU I / F' block 896. There are 30 registers on both channels. Each register has A, B, C and D bits of two POTS lines. For example, register # 1 has signal bits of POTS # 1 (low 4 high bits) of Ch1 and POTS # 2 (high 4 high bits) of Ch1. Register # 16 has signal bits of POTS # 1 (low 4 high bits) of Ch2 and POTS # 2 (high 4 high bits) of Ch2.

CT812 (called 'timeslot exchange') 858 may route any timeslot location from the backplane side to the local side or vice versa. There are 32 lines that connect with the backplane. Each line is bidirectional and has a data rate of 8.192Mhz (128DSOs). The local side has eight lines of transmit output and eight lines of receive input. Only four are used on the transmitting and receiving side. Each line carries data at 4.098Mhz (64 timeslots).

The CT812 includes SCLKX2 (16.384 MHz), SCLK (8.192 MHz) and FSYNC to obtain external clocks and syncs from the backplane. The device generates local clock (L_CLK) and frame sync (L_FS) signals. CT812 provides an interface between the backplane message channel signal 30 and the local HDLC controller 862.

Bus switch 860 is designed for power increase in high-impedance conditions. This isolates the module from the backplane's TDM signals, clocks and message channels, providing hot-swap capability. The bus isolation module is controlled by switch 861 under the control of shelf manager SM21.

The HDLC controller 862 processes the messages passed between the onboard CPU and the shelf manager SM21. 80C51XA micro-controller 864 provides proper timing, control and communication functions between the system and the board. The 80C51XA clock speed is 20.2752MHz.

CPLD 866 performs address decoding, generates chip selections for control signals and CPU peripherals, generates standby states for the CPU when connecting to low speed memory mapping devices, and clocks required by CT812. Generate.

As mentioned above, the signal bit swizzler block 857 of the 2SDSL RM 820 (FIG. 64) is designed to receive downstream signal data in the provided sequence and rearrange the output sequence of signal bits. The actual rearrangement is programmable through software and follows the cross link in the SDSL RM. The manner in which the LAS14 shelf transfers signal information between the cards via DS0s on the backplane is described above in connection with FIG.

During each frame, signal slot timeslot # 2 (832 FIG. 62A) designated to carry a signal signal is received by the SDSL FPGA. The bit format of each signal slot is described with reference to Table 8.

For the SDSL signal bit swizzler 857, the reserved bit b8 is treated as a valid signal bit for use with the E1 digital signal transmission format. As each frame is received, the signal bits are extracted from the exact bit position of each signal slot to form the extended signal channel matrix shown in Table 9 above.

Operation of the signal swizzler 857 is now described with reference to FIG. 67. Swizzler 857 includes an output sequencer register file bank 902, an output sequencer phase generator 904, and an input sequencer phase detector 906. Also included are a 30: 1 multiplexer 910, an index counter 912, an address counter 908, a dual port memory 914, a 60: 1 multiplexer 916 and a 4: 1 multiplexer 918.

As the extended frame format suggests, each step of the ESF consists of six frames, each with five signal bits. Thus, for each step, a 30 bit memory 914 is used to store the signal information. This memory has the following format shown in Table 41.

Table 41

To control the output sequence, the signal bit swizzler 857 is a file 902 sequentially rotated by the read (or output) sequencer 904 using the index controller 912 and the 30: 1 multiplex 910. Provide 30 5-bit registers. Each of these registers has a 5-bit address of signal bits and is output in the required order. Table 42 shows the 30-output register banks.

Table 42

The contents of this register bank 902 as well as the signal memory 914 determine which of the 30 signal input bits is the output and what sequence. For example, to connect signal bit S ₁₇ to output signal bit 1, the address of S ₁₇ in signal memory 0x14 is loaded into R ₀ . In order to connect the input signal bit S ₂₁ to the output signal bit 2, the address of S _{21 in} the signal memory 0x19 is loaded into R ₁ . These signal bits used are only needed to be programmed into the register bank. However, by loading Ox1F into an unused register, all remaining signal bits are set to one. When Ox1E is loaded into the register, all remaining signal bits are set to zero.

The actual output format of the signal data is shown in Table 43.

Table 43

Here, S (Rx) means signal bits in the signal memory indexed indirectly by the contents of the register (x).

The following example shows the behavior of the swizzler. Assume that the following values are loaded into register bank 902.

Table 44

In this example, the output signal slot data is shown in Table 45.

Table 45

The output signal byte with swizzled signal data is inserted in slot 2 of the FPGA output frame as shown in FIG. 62A. The swizzler inserts all 1s into slot 2 whenever the input sequencer 906 is not synchronized with the input P bits or seeks synchronization. If an error occurs during this signal repetition period, sequencer 906 performs a reset and attempts to resynchronize with the input P bits. Again, all 1s are output until proper P-bit synchronization is achieved.

SMU2

SMU2 shown in FIG. 7 is a line card capable of performing system clock generation, user interface, and alarm control. One embodiment of a shelf manager SMU2 with an improved processing core, additional memory, an Ethernet interface, a PCMCIA FLASH disk interface, and an SCSA bus interface device that enables direct connection of an SM to backplane DS0s is now described with reference to FIG. 68. .

The SMU2 features an MPC860MH processor 930, FLASH program memory 932, DRAM memory 934, nonvolatile SRAM memory 936, optional on-board PCMCIA flash disk 938, CT-812 SCSA universal timeslot exchanger 940, Field Programmable Gate Array (FPGA) 942, Real Time Clock 944, On-Board Power Supplies 946, 948, Power / Battery Monitor 950, SCSA Bus Disconnect Switch 951, 953, Ethernet Support circuit 954, and various clock oscillators and VCXOs 956 for system timing.

SMU2 uses the Motorola MPC860MH as the main processor 930. These processors run at a 25MHz clock rate derived from an external 32.768KHz crystal and Ethernet PLL. The MPC860 has a 32-bit data bus and a 32-bit address bus and integrates with data and instruction caches and large Ethernet architectures. This architecture results in improved performance with execution speeds of more than one instruction / clock cycle.

The MPC 860 includes an 8-bank memory controller to gluelessly connect to SUM2's FLASH, DRAM, MVSRAM and other peripherals. This memory controller utilizes a user programmable machine (UPM) pair and a general purpose chip-select machine (GPCM) for complex sequencing and timing. The memory controller also provides the ability to perform burst operations, standby insertion, internal / external transmission acknowledgments, and memory range monitoring.

The SMU2 utilizes the MPC860's integrated PCMCIA host adapter / controller 960 to access a fully captive on-board solid state flash disk 938. These controllers only require external drivers and transceivers to implement the fully compliant PCMCIA2.1 true IDE interface.

SMU2 also uses the digital I / O port 962 of the MPC860. These ports are used to generate signal timing / sequencing for FPGA downloads and to access the serial real time clock (RTC) 944.

The main feature of the MPC860 used by the SMU2 is the communication processor module (CPM). CPM provides a flexible approach to SMU2's enhanced communications environment. The CPM has its own RISC communication processor suitable for serial communication. These RISC processors can service multiple integrated communications channels, thereby processing and controlling serial channel DMA operations with low-level protocols. The MPC860MH provides two full duplex communications and serial management controllers (SMCs) and four full-duplex serial communications channels (SCCs). The SMC1 964 provides the system user with an RS-232 text-based interface through the SMU2's front panel and via an extra RJ-45 connector 965 on the backplane. This interface acts as a subset of system management software.

SMU2 uses SCC1 966 of MPC860 to provide a 10BASE-T Ethernet interface to a backplane 941 that supports the IEEE 802.3 CSMA / CD LAN protocol. This interface is used as an alternative high speed interface of the SMC1 interface. The external PHY level Ethernet transceiver and its associated transformer 954 are the external devices needed to implement the protocol compliant interface.

SCC2 968 of MPC 860 is used by SMU2 in HDLC bus mode to communicate over a system message channel. SMU2 operates such a channel at 2.048 Mb / s and uses a 32 data-byte frame format as described above. The message channel runs as a single line in bus mode that allows it to operate as a point-multipoint LAN. MPC 860 is configured in this mode to take advantage of options for hardware collision detection and retransmission.

The SCC4 970 of the MPC 860 is used by the SMU2 in HDLC mode but connected to the CT-812 TSI 940 via a time division multiplexing (TDM) serial controller. Using the internal timeslot allocator (TSA) to divide the control strobe from the CT-812 into frames, normally contiguous HDLC streams are cut into 8-bit slices and inserted into one of the 32 slots in the frame. Although each individual message takes a long time to transmit, this technical feature allows multiple simultaneous messaging that can utilize the full bandwidth of the 2048-timeslot backplane. This feature enables useful communication with other resource modules.

SMU2 uses several memory devices for various purposes. These memory devices are PCMCIA flash disk 938, on-board FLASH EPROM 932, fast page mode (FPM) DRAM 934 and battery back SRAM 936.

SMU2 integrates two 1M × 16 bit FLASH EPROM devices 932 for boot code storage. These devices are accessed from the MPC 860 through the chip selector 1 using the GPM of the memory controller of the MPC 860. Using a 90ns device, it can be read and written using only a single standby @ 25MHz processor clock rate.

SMU2 incorporates two 4M × 16 bit FPM DRAM devices 934 for temporary storage needs. This results in a total DRAM capacity of 16M bytes. These devices are accessed through the chip selector 1 of the MPC 860 using UPM for signal / strobe timing and sequencing. Although configured as 32 bits, the DRAM bank can be accessed as an 8-bit byte, a 16-bit word, or as a 32-bit long word. Using a 60ns device, a single bit access can be performed using the 1-standby state and the total access time of three clock cycles. However, because these devices are in fast page mode, multi-word burst access helps to significantly reduce the average access time. These burst accesses are essential for cache fill operations that enhance the performance of MPC 860.

The SMU 2 has a single 128K × 8 bit static RAM 936 backed up by the on-board lithium battery 952 when power is removed from the board. Access to this device is via the tip selector 4 of the MPC 860 using the GPM to control signal strobes and timing. These 85nS devices only require a single standby state for normal operation.

The SMU 2 has an on-board PCMCIA interface (socket) configured for true-IDE mode operation. This socket is connected to a type II PCMCIA solid state flash disk 938 that can provide storage with a capacity of up to 300 Mbytes. This device is used by MPC 860 type hard disks and stores program information that is accessed after SMU2 boot from FLASH. Access to these devices is via the PCMCIA adapter of MPC 860 with the addition of external drivers and transceivers.

The requirement of the SMU2 for maximum access to the Signal Computing System Architecture (SCSA) backplane bus 941 is achieved by using the CT-812 universal timeslot exchanger 940. Such a device provides a connection between a telephone or signal processing resource and a backplane bus. This device is also accessed by the MPC 860 for configuration and status through an 8-bit port using the chip selector 2 and the GPM memory controller of the MPC 860. The actual CT-bus TDM data is sent to the MPC 860 via the CT-812 by the timeslot allocator in TDM mode. Timing for the CT-812 is provided by the "frame sync" generated by the field programmable gate array (FPGA) of the SMU2 and by an on-board 16.384 MHz layer IV oscillator. Although the CT-812 has the ability to support 32 CT bus lines, only 16 are used on the backplane.

SMU 2 uses a battery supplemented real time clock module 944 with integrated crystals to provide accurate clock resources to the system shelf. When accessed as a 52-bit serial frame, MPC 860 provides data, clock, and write control strobes to read / write the device. Using an on-board lithium battery, the device operates in a low power mode when power is removed from SMU2. The device can vary by two minutes every month.

The SMU2 has six alarm relays 972 connected to twelve signal lines connected to the backplane and is accessible through terminal blocks on the backplane. Alerts fall into two categories, visual and auditory, and are further defined by three depth levels: minimum, major, and threshold. Alarm relays are used by system shelves to notify the outside world of fault conditions. Each relay has an associated jumper to configure an alarm contact for a normal opening or a normal closing. Since a 48V voltage is supplied to the relay, the SMU2 integrates two TTL level translators for relaying. The relay is controlled by the processor through a register in the FPGA.

The FPGA 942 of the SMU2 includes the logic necessary to interface the rest of the system. FPGAs include logic to perform tasks including clock recovery, clock generation, state I / O, phase locked loop (PLL), alarm control, and automatic disconnection interfaces.

The FPGA includes logic used in conjunction with an external lowpass filter 957 and a voltage controlled crystal oscillator (VCXO) 956 to form a phase locked loop (PLL) used for clock recovery. The VCXO operates at a center frequency of 32.768 MHz. The frequency is adjusted according to the pulse width output by the phase identifier in the FPGA. These output pulse streams are integrated through the LPF and generate a bias voltage that controls the frequency. The reference source for the PLL is software selectable from one of five sources: on-board 16.384 MHz layer IV oscillator, central station synthesized clock, or loop recovery clock (1, 2, 3). The loop recovery clock is derived from the input data stream in either the BRI or DSX resource module. The FPGA also includes logic to monitor the integrity of each selected clock and report errors to the processor via interrupts.

The FPGA includes logic to generate a clock based on the output of the 32.768 MHz VCXO. By using a counter, the FPGA generates SCLKx2 and FSYNC signals that connect to each RM in the backplane and synchronize all operations.

The FPGA also includes logic used to provide status and other information from the backplane to the processor. When operating as a buffer, the FPGA allows the processor to access 5-bit backplane modification fields, 5-bit slot ID fields, 4-bit shelf ID fields, and 3-bit alert input fields. The FPGA also accesses the backplane status signals CLKFAIL and CTERM.

Optionally, the FPGA includes status output bits to control other devices on the SMU2 circuit board. These devices include three front panel LEDs, alarm relays, and enable buses for disconnect bus switches and system CLKFAIL signals.

The SMU2's FPGA contains logic to run an automated one-line protocol sequencer. Each RM in the system shelf has a separate line for SMU2 that is used to enable or disable the RM. An addressable switch on each RM requires a 72-bit data stream to turn the bus switch on or off. The processor starts the sequence by setting a single bit and is interrupted by the FPGA 2ms after the auto sequence is complete. Errors during the sequence cause an interrupt to the MPC860. The processor controls the selection of one of the 25 disconnected interfaces on the FPGA. Further information on the disconnection protocol is found in the 1405 Addressable Switch Product Specification by Dallas Semiconductor.

The FPGA is accessed by the processor as an 8-bit device using the chip selector 3 and does not require a standby state for normal operation.

Each resource module and SMU2 may be completely isolated from the SCSA backplane by bus switches 951 and 953. These switches are disabled devices that are enabled through the processor on each RM. These switches can be disabled by SMU2 if the shelf manager determines that a system fault has been caused by a defective RM. The signals isolated from the SMU2 via a bus switch are 25 single wire control signals, system clock, system frame sync, 16 CT buslines and message channel lines. On the SMU2, the bus switch is controlled via two signals, BUSEN and CLKEN, which are controlled by the processor via the FPGA.

EPRM2

Hereinafter, the Ethernet protocol resource module (EPRM2Z) is described. The EPRM2 module is a protocol adapter module that centralizes encapsulated MAC frames from multiple subscribers into a single 10 / 100Base-T interface.

EPRM2 offers the following features:

4-wire 10Base-T / 100Base-TX interface on the backplane

XDSL subscriber support at Nx64 Kbps, where N is 2-32

256 full duplex communications DS0 timeslot or maximum bandwidth equal to 16.384Mbps

· MAC layer bridging support

Interoperability with Integrated Access Devices

Interoperability with iDSL network extensions

EPRM2 allows Internet Service Providers (ISPs) to access their customers at central offices without using the usual exchanges. 69 shows the configuration. EPRM2 1200 provides integration for small businesses and SOHO and 10 / 100Base-T backhaul to IDSL devices 1205 via iDSL 1201, integration for large businesses and “extranets” and 10 / 100Base-T backhaul is provided to IAD 1207 via SDSL 1203. In this structure, subscribers are connected using BRI and SDSL circuits. In particular, the iDSL subscriber is connected to the shelf 14 via multiple 4BRI circuit packs (not shown).

EPRM2 1200 is a bridge between 10 / 100Base-T and Ethernet frames encapsulated in the backplane DS0, and the Ethernet port acts as an "uplink" port. EPRM2 1200 complies with the requirements defined in IEEE Std 802.1Q-1998.

EPRM2 relays individual MAC user data frames between its various ports. The port can be either an HDLC port or an Ethernet port dynamically configured by the management system through an interconnection to the backplane. The HDLC port is connected to a similar device (eg, IAD) that performs auto relay to Ethernet.

EPRM2 1200 includes an Ethernet port for transmitting and receiving Ethernet frames in accordance with IEEE 802.3. Detected reception errors may include elements specified in IEEE 802.3, i.e., frame lengths (when it contains lengths) that do not match the length values specified in the Ethernet frame length / type field, b) non-integer octets. Or c) the generated CRC is a frame that does not match the received frame. In addition, the "runt" frame (as defined in IEEE 802.3 paragraphs 4.4.2.1 and 3.1.1) is considered as a reception error. Frames received with an error are discarded.

The Ethernet port supports 10BASE-T and 100BASE-TX, and the speed may be an optional option or may be allowed to set itself through "auto-negotiation". The Ethernet port supports half duplex communication mode and full duplex communication mode.

EPRM2 1200 includes one or more HDLC ports that transmit and receive encapsulated Ethernet frames in HDLC per RFC 1662 using selectable formats. The supported choices are:

Compressed HDLC (C-HDLC) (described in "Address and Control Field Compression" in paragraph 3.2 of RFC 1662).

Standard HDLC (HDLC)

PPP

70 illustrates the WAN encapsulation for an Ethernet frame in detail.

Hereinafter, the EPRM2 1200 illustrated in FIG. 71 will be described. The Motorola MPC860 is used as the processing platform 1202 for EPRM2. The device utilizes a 32-bit data and address bus. The function of this processor has been described above with respect to SMU2 and FIG.

EPRM2 supports 16 MB of DRAM memory 1204 consisting of two 8 M bit portions configured as 4 Mx32 bits. Such memory can be used to store programs or data. The memory is also directly connected to the MPC860 via the GPM memory control.

EPRM2 includes an FPGA 1208 that includes various system control registers as well as clock generation and frame synchronization circuits. These system control registers are used for LED control, clock control, and input states. The FPGA is accessed as a byte peripheral and selected through the MPC860 chip selector.

EPRM2 accesses the system SCSA bus 941 via the CT-812 bus system interface controller 1210. This access is provided as parallel access and serial access to the backplane over one of the HDLC channels of the MPC860 configured for TDMA operation. These devices are accessed as byte-based peripherals and are selected via the MPC860 programmable chip selector.

Bus isolation and hot swap support are provided by a set of bus isolation FET switches. The EPRM2's CPU may enable or disable the bus connection to the backplane or enable or disable the clock connection to the bus via a separate signal from the FPGA. Bus switches are designed to have high impedance when the circuit card is disabled because no power is supplied to the circuit card.

EPRM2 1200 further includes a multichannel synchronous communication controller 1212 (implemented as Conexant device MUSYCC-CN8478) and an Ethernet controller 1214. The Ethernet controller 1214 may be an Intel 82559 device that provides a media access controller (MAC) 1218 and a physical layer (PHY) interface 1216. In operation, multichannel HDLC encapsulation data from backplane bus 941 is sent to MUSYCC 1212 and then to RAM 1204. Then, data from RAM 1204 is multiplexed onto a single Ethernet channel via Ethernet controller 1214. This process is bidirectional.

Although the present invention has been described with reference to the examples, those skilled in the art should understand that the present invention can be modified without departing from the spirit and scope of the invention as defined in the appended claims. It will be apparent to those skilled in the art that the methods included in the present invention may be embedded in a computer program product comprising a computer-use medium. For example, a computer-used medium may include a readable memory device (where computer readable program code segments are stored), such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette. The computer readable medium may include a communication or transmission medium, such as a bus or communication link, which is either optical, wired or wireless, and may also carry program code segments as digital or analog data signals.

Those skilled in the art will be able to understand the embodiments equivalent to the specific embodiments of the invention described herein using routine experimentation. These and all other equivalent embodiments are defined by the following claims.

Claims (41)

A plurality of exchangeable resource modules for providing an interface for various network communication services; And A management unit for monitoring each resource module on the message channel, Each resource module communicating with the management unit over a message channel. The method of claim 1, Using an interface between any resource module and any other resource module, an interconnection is established by an operator via a message from a management unit to a message channel, The management unit holds in the memory common settings and configurations for the resource modules, initializes and synchronizes timing functions in each resource module, and provides a management interface for each module. The method of claim 2, The interface is accessible via a management unit, which allows the user to manage system resources and maintain system components by connecting the management unit to a menu-based control screen. The method of claim 1, A module that detects a contention immediately gives up its message and enters a high impedance state and remains in a high impedance state until an idle state is detected by the module in the contention state, when the idle state is detected. The module may include such a contention detection protocol that may transmit one bit frame but does not transmit another bit frame until at least five or more consecutive "one" bits are detected on the control channel. System. A communication system that provides subscribers with access to a variety of network services and protocols including ATM, frame relay, and IP, A plurality of resource modules that provide an interface between subscribers and network services; A management unit for monitoring each resource module on the data bus, each management unit having at least one processor that stores provisioning information for each resource module, the at least one resource module receiving supply information from the management unit; Has a receiving processor, A message channel for providing communication between resource modules and a management unit; And A communication system comprising an interface that enables a user to manage resources as a graphical user interface accessible through the screen of the management unit. The method of claim 5, The management unit downloads the supply information to each resource module on the message channel. The method of claim 6, Each resource module is assigned one or more data bus unique timeslots for receiving and transmitting digital information, and an interconnection is established between any resource module and any other resource module by the management unit to provide full time for each module. A communication system characterized by providing full time slot interchangeability. The method of claim 7, wherein A communication system comprising a bus contention protocol. In a graphical user interface for an access system, which allows a user to practice, configure and test system units, And a display providing N possible functional screens, including an operation screen, an interconnect map screen, and a management map screen, wherein each screen supports an N-object level when N = 3. The method of claim 9, Graphical user interface, characterized in that the object levels are shelves, equipment, and interfaces. A graphical user interface for an access system comprising a shelf arranged to be adjacent to each other and side by side and containing a plurality of modules each having a separate screen, A display divided into multiple screens, One of a number of screens is a hierarchical screen that depends on user selection, and the first screen of the hierarchy is a graphical user interface that collectively represents the currently available shelf. The method of claim 11, Graphical user interface, comprising additional and selectable screens for individual modules, interfaces on modules, and interconnections between interfaces. The method of claim 11, Includes an area with some selectable indicia screens, The first display allows the user to proceed to another screen in another area or to return to the previous screen of another area. The second display allows the user to display processing, status / alert reporting, and management information for various modules in different areas. The method of claim 13, A third indication that allows a user to establish an interconnect on the modules; And And a fourth indication that allows the user to access and select management functions for the modules. A communication system that provides subscribers with access to various network services, A plurality of resource modules that provide an interface to network services; A management unit for monitoring each resource module on the first bus, each resource module including at least one processor that stores supply information for each resource module; It includes a second bus that provides communication between the resource modules and the management unit during start-up, the first bus providing each module with the ability to read and write from any timeslot to complete timeslot interchange. Gaining abilities, and You (a) configure each resource module, (b) interconnect mapping resource modules; (c) track the status of resource modules, (d) to report incidents, alarms and statistics; (e) A communication system comprising a graphical interface that enables performing functions for testing and maintaining resource modules. The method of claim 15, Each resource module is connected to and accessed from a management unit, and the software upgrade provision of the resource modules is provided on a message channel using a predetermined set of protocol messages. A communication system that provides subscribers with access to various network services, It includes a number of resource modules that provide an interface to network services, each resource module including a transient protection circuit to protect the resource module from high-voltage transients, subscribers and network A speed conversion unit for converting an operation speed of the resource module from a backplane I / O interface between services to a data rate of input data coupled to the resource module; A management unit for monitoring each resource module on a bus, each resource module including at least one processor that stores supply information for each resource module; And A graphical interface comprising a computer coupled to the communications system to enable a user to operate, maintain, and monitor resource modules. The method of claim 17, Wherein each module is arranged in slots and is interchangeable and is configured via a message channel communicated on a bus from an interface by a user. The method of claim 18, The slots are provided on one shelf and the management unit is contained in one of the slots. A method of interfacing various network services to subscribers using various resource modules having interfaces for establishing a data point between any two modules and interconnecting one module to another, wherein the resource modules are user An interface method, which is supplied and maintained from management units operable from an interface, wherein the management units communicate digital messages on a message channel, (a) providing transmission and reception of timeslot assignments from the management unit to the resource modules; And (b) establishing configurable parameters to define a valid interconnect. The method of claim 20, The parameters are (a) identifying one interface at the first side of the interconnect; (b) identifying one interface at the second side of the interconnect; (c) providing the number of signal bits needed to support the interconnect; (d) providing an insertion word for transmission in the event of an alarm condition occurring; (e) providing a value for signal bits to be transmitted from the first side interface of the interconnect to the second side of the interconnect in the event of an alarm condition occurring; (f) providing a value for the signal bits to be transmitted from the second side interface of the interconnect to the second side of the interconnect in the event of an alarm condition occurring; And (g) establishing at least one primary service state for the interconnection. In a communication system having a plurality of resource modules for providing a communication service and a backplane communication bus for interconnecting the resource modules, the bus includes voice timeslots for carrying voice information and one or more corresponding voice times. A plurality of backplane timeslots including signal timeslots for carrying signal information for slots, the improved resource module comprising: Backplane interface circuitry for selecting backplane voice and signal timeslots from a backplane communication bus; And A multiplexer circuit for multiplexing selected backplane voice and signal timeslots into a downstream signal, And the multiplexer circuitry comprises a signal mapper that maps signal information from each selected backplane signal timeslot to a common downstream signal timeslot. The method of claim 22, And the downstream signal has a frame format including M < RTI ID = 0.0 &gt; M &lt; / RTI &gt; downstream voice timeslots and M downstream timeslots comprising a common downstream signal timeslot. The method of claim 23, wherein The backplane communication bus further includes backplane data timeslots that carry data information, and the downstream frame format further comprises downstream data timeslots. The method of claim 22, And a line interface circuit for converting the downstream signal into a digital subscriber line format for transmission to a downstream integrated access device. The method of claim 21, And the signal information includes in-band signaling. The method of claim 26, And the signal information includes ABCD signal bits. A plurality of resource modules providing a communication service and a backplane communication bus interconnecting the resource modules, the backplane communication bus comprising voice timeslots for carrying voice information and one or more corresponding voice timeslots. In a communication system having a plurality of backplane timeslots comprising signal timeslots for conveying signal information for the at least one resource module, Backplane interface circuitry for selecting backplane voice and signal timeslots from the backplane communication bus; A multiplexer circuit for multiplexing selected backplane voice and signal timeslots into a downstream signal, the multiplexer circuitry mapping a signal information from each selected backplane signal timeslot to a common downstream signal timeslot. It includes; And A line interface circuit for converting a downstream signal into a digital subscriber line format for transmission to a downstream integrated access device. The method of claim 28, And the downstream signal has a frame format including M < RTI ID = 0.0 &gt; M &lt; / RTI &gt; downstream voice timeslots and M downstream timeslots comprising a common downstream signal timeslot. The method of claim 29, The signal information includes an in-band signal. The method of claim 30, The signal information comprises ABCD signal bits. A plurality of resource modules providing a communication service and a backplane communication bus interconnecting the resource modules, the backplane communication bus comprising voice timeslots for carrying voice information and one or more corresponding voice timeslots. A method of communicating in a communication system having a plurality of backplane timeslots comprising signal timeslots for carrying signal information for Selecting a backplane voice and signal timeslot from the backplane communication bus; And Multiplexing the selected backplane speech and signal timeslots into a downstream signal, the method comprising multiplexing signal information from each selected backplane signal timeslots to a common downstream signal timeslot; Communication method. 33. The method of claim 32, And the downstream signal has a frame format including M < RTI ID = 0.0 &gt; M &lt; / RTI &gt; downstream voice timeslots and M downstream timeslots comprising a common downstream signal timeslot. The method of claim 33, wherein Converting the downstream signal into a digital subscriber line format for transmission to a downstream integrated access device. A plurality of resource modules providing a communication service and a backplane communication bus interconnecting the resource modules, the backplane communication bus comprising voice timeslots for carrying voice information and one or more corresponding voice timeslots. In a communication system having a plurality of backplane timeslots including signal timeslots for conveying signal information for an improved resource module, Backplane interface circuitry for selecting a first voice and signal timeslot from the backplane communication bus and for applying second voice and signal timeslots on the backplane communication bus; Line interface circuitry for converting a downstream PCM signal into a downstream DSL signal for transmission to the integrated access device and for converting an upstream DSL signal from the integrated access device into an upstream PCM signal; A multiplexer circuit for multiplexing the first voice and signal timeslots into a downstream PCM signal; And And a demultiplexer circuit for demultiplexing the upstream PCM signal into second voice and signal timeslots. 36. The method of claim 35 wherein The downstream PCM signal has a frame format comprising M downstream timeslots comprising N <M downstream speech timeslots and a common downstream signal timeslot. The method of claim 36, And wherein the multiplexer circuitry comprises a downstream signal mapper that maps signal information from respective first signal timeslots to a common downstream signal timeslot. The method of claim 37, And the signal information includes an ABCD type in-band signal. 36. The method of claim 35 wherein The upstream PCM signal has a resource module having a frame format comprising M upstream timeslots including N <M upstream voice timeslots and a common upstream signal timeslot. The method of claim 39, The demultiplexer circuit comprises an upstream signal mapper that maps signal information from a common upstream signal timeslot to second signal timeslots. A communication bus for carrying HDLC encapsulated Ethernet frames; A subscriber resource module coupled to the communication bus to transmit downstream HDLC-type Ethernet frames to an external integrated access device and to receive upstream HDLC-type Ethernet frames from an external integrated access device; And A communication system comprising an Ethernet protocol resource module, wherein the Ethernet protocol resource module includes: An Ethernet port for receiving downstream Ethernet frames from an external data network and transmitting upstream Ethernet frames to an external data network; An HDLC port for transmitting downstream HDLC-type Ethernet frames to a communication bus and receiving upstream HDLC-type Ethernet frames from the communication bus; And And a protocol converter for converting downstream Ethernet frames into downstream HDLC-type Ethernet frames and converting upstream HDLC-type Ethernet frames to upstream Ethernet frames.