WO2000002365A1 - Systems and methods for utilizing a communications network for providing mobile users access to legacy systems - Google Patents

Systems and methods for utilizing a communications network for providing mobile users access to legacy systems Download PDF

Info

Publication number
WO2000002365A1
WO2000002365A1 PCT/US1999/014626 US9914626W WO0002365A1 WO 2000002365 A1 WO2000002365 A1 WO 2000002365A1 US 9914626 W US9914626 W US 9914626W WO 0002365 A1 WO0002365 A1 WO 0002365A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
server
data
legacy
legacy systems
Prior art date
Application number
PCT/US1999/014626
Other languages
French (fr)
Inventor
Robert H. Willis, Jr.
David R. Jean
William L. Harris
Original Assignee
Telcordia Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telcordia Technologies, Inc. filed Critical Telcordia Technologies, Inc.
Priority to AU50856/99A priority Critical patent/AU5085699A/en
Publication of WO2000002365A1 publication Critical patent/WO2000002365A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates in general to the field of telecommunications dispatching systems and in particular to the field of wireless and wireline communications providing mobile personnel access to legacy systems and other remote systems.
  • Telecommunications technicians perform a variety of functions for telecommunications companies. Among the critical functions they serve includes providing on-site installation and maintenance service support to customers. While on the customer's premises and when preparing for a customer visit, mobile personnel such as technicians need access to a variety of data, and systems such as, facility assignments, network testing functions, maintenance processes and procedures and customer specific information. Typically, the remote systems provide access to systems such as dispatch, facilities, and billing systems.
  • the legacy systems include a collection of databases established by the Bell System and currently managed by BellCore provide critical information necessary for technicians to complete their job duties.
  • CAS Craft Access System
  • CAS provides access to many of these functions though a variety of legacy systems.
  • Legacy systems include Loop Facility Assignment Control System (LFACS), Loop Maintenance Operations System (LMOS), Computer System for Main Frame Operations (COSMOS). Mechanized Loop Testing (MLT), Secure Network Element Contract Server (SNECS), Mechanized Time Reporting (MTR), OutSide Plant Construction Management (OPSCM) and Work Activity Statistical Sampling Plan (WASSP).
  • LFACS Loop Facility Assignment Control System
  • LMOS Loop Maintenance Operations System
  • COSMOS Computer System for Main Frame Operations
  • MKT Mechanized Loop Testing
  • SNECS Secure Network Element Contract Server
  • MTR Mechanized Time Reporting
  • OPSCM OutSide Plant Construction Management
  • WASSP Work Activity Statistical Sampling Plan
  • LFACS a part of the Facility Assignment and Control System (FACS) is primarily responsible for completing outside plant facility assignments.
  • COSMOS provides methods to effective manage, control and utilize main central office distributing frame facilities and circuits. This is accomplished by automating the assignment of central office equipment, telephone numbers, and frame cross connections. A selected sample of outside plant technicians are selected each month to utilize WASSP to report how much time they spend doing different tasks on each job they complete. This data is verified and sent to the MTR system.
  • LMOS is further delineated into LMOS Host and LMOS Front End (FE).
  • LMOS Host stores and maintains detailed line record information. It also creates and maintains historical data on closed trouble reports.
  • LMOS FE provided mechanized methods of maintaining customer line records and mechanized capability for entering, processing and tracking trouble reports.
  • MLT is an automated loop testing system available through LMOS FE. It is used to test loops equipped with one-party and commercial services such as Private Branch Exchange (PBX) and Central Office Centrex.
  • PBX Private Branch Exchange
  • SNEC is a security interface.
  • OPSCM is designed to manage outside plant construction from end to end. It encompasses contracts, contractors, job management, complaints, billing and payments, and informational reporting. These systems provide the required data utilized by technicians to install and maintain services. While CAS provides access to legacy systems, CAS has limitations. CAS is a
  • Lucent Technologies proprietary system which in some versions is expected to be unable to function beyond the year 2000.
  • CAS requires technicians to use a dial-up connection to access the information systems they need to perform their job, requiring them to find dial tone.
  • technicians access CAS utilizing Computer Access Terminals (CATs), also referred to as "the brick”.
  • CATs require technicians to use a dial-up connection to transmit data at 1.2 kbps. This process restricts the technicians mobility while using the system.
  • the technician must either gain permission of a customer to tie up their phone line or leave the customer premise, drive to a location where the technician can plug in a computer terminal and log in.
  • Technicians are placed in the position of either tying up a customer's phone or driving to find dial tone. Both are inefficient methods of communicating with the network.
  • CATs are slow. CATs are DOS based script orient computers with no memory, i.e. it is a dumb terminal. Only a single task is available at a time utilizing CAT.
  • LMOS provides critical customer information and serves as a tracking mechanism for trouble reports and expectedly, technicians frequently access LMOS.
  • LMOS provides critical customer information and serves as a tracking mechanism for trouble reports and expectedly, technicians frequently access LMOS.
  • the present invention addresses the problems associated with CAS technician dispatch systems and provides additional capabilities and features not available utilizing CAS.
  • the methods and systems of this invention provide for a Year 2000 compliant distributed client-server application for mobile personnel with reliable and secure access to remote systems, such as legacy systems.
  • the preferred system associated with this invention for discussion purposes will be referred to in a non-limiting manner as TechNet.
  • the TechNet system includes portable personal computers in communication with a wireless or wireline communications network, protocol servers for receiving and forwarding messages to and from the portable personal computers, the protocol servers in communications with a TechNet server in communications with legacy systems and other remote systems.
  • the technicians are equipped with ruggedized notebook computers that provide two-way wireless and wireline communication. Data can be transmitted up to 33.6 kbps via wireline connections and up to 8 kbps wirelessly.
  • Wireless service utilized by the technicians to connect to the TechNet servers is preferably through the BellSouth Wireless Data Network (BSWD) although other wireless networks may be used.
  • Wireline service or dial-up service utilized by the technicians to connect to the TechNet servers is through the BellSouth Communications Network (BSCN) but again other wireline networks may be used.
  • BSCN BellSouth Communications Network
  • Protocol servers preferably manufactured by NetTech, provide protocol conversion and middleware service in the TechNet system.
  • the TechNet server provides for receiving user requests, authenticating user access, servicing user requests, generating legacy system transactions, providing an interface and emulation to legacy systems, receiving results from the legacy systems and sending results back to the users portable PC.
  • Legacy systems contemplated as part of this invention for RBOCs include but are not limited to, Loop Facility Assignment Control System (LFACS), Loop Maintenance Operations System (LMOS), Computer System for Main Frame Operations (COSMOS), Mechanized Loop Testing (MLT), Secure Network Element Contract Server (SNECS), Mechanized Time Reporting (MTR), and Work Activity Statistical Sampling Plan (WASSP).
  • LFACS Loop Facility Assignment Control System
  • LMOS Loop Maintenance Operations System
  • COSMOS Computer System for Main Frame Operations
  • MKT Mechanized Loop Testing
  • SNECS Secure Network Element Contract Server
  • MTR Mechanized Time Reporting
  • WASSP Work Activity Statistical Sampling Plan
  • a ruggedized laptop personal computer provides a flexible platform which enables future improvements in information systems and allows the technician to provide better service to customers.
  • Objects of this invention include:
  • FIG. 1 presents a broad overview of a system 1 for providing personnel remote access to legacy systems in accordance with a preferred embodiment of this invention.
  • FIG. 2 shows a high-level flow chart of the processes utilized by the system 1 of Figure 1.
  • FIG. 3 shows an overview diagram of an architecture of a TechNet system according to a preferred embodiment of this invention.
  • FIG 4 shows a flow diagram of a TechNet client application.
  • Figure 5 shows an overview of the TechNet communications layer software configuration.
  • Figure 6 shows a diagram of an architecture including a TechNet portable PC in communication with a protocol server utilizing a communications network.
  • Figure 7 shows an embodiment of the BellSouth Wireless network (BSWD) switching network.
  • Figure 8 shows a wireless inbound routing configuration.
  • BSWD BellSouth Wireless network
  • Figure 9 shows a wireless outbound routing configuration.
  • Figure 10 shows an example of a Host Group Addressing (HGA) configuration.
  • Figure 11 shows a wireline inbound routing configuration.
  • Figure 12 shows a wireline outbound routing configuration.
  • Figure 13 shows an illustration of protocol server grouping.
  • HGA Host Group Addressing
  • Figure 14 shows a more detailed view of a configuration of the array of protocol servers of Figure 13.
  • Figure 15 shows an illustration of the protocol server architecture.
  • Figure 16 shows an illustration of inbound message processing utilizing the protocol server architecture of Figure 14.
  • Figure 17 shows an illustration of outbound message processing utilizing the protocol server architecture of Figure 14.
  • FIG 18 shows an overview of an arrangement of TechNet servers deployment.
  • Figure 19 shows an illustration of a TechNet server software configuration.
  • Figure 20 shows a flow diagram of a Hands Off Assignment Logic (HAL) interface to legacy systems.
  • HAL Hands Off Assignment Logic
  • Figure 21 shows an example of TechNet server components utilized in each data center.
  • the communications network may include a wireless network and a wireline network available as a backup network when personnel are unable to utilize the wireless network.
  • the communications network includes a variety of networks, for instance local, long distance, and cable networks.
  • FIG. 1 presents a broad overview of a system 1 for providing personnel, such as a mobile workforce, access to remote systems in accordance with a preferred embodiment of the invention.
  • the system 1 includes a processor 2, a communications network 3, a system interface 4, a network 3 A and remote systems 5.
  • Figure 2 shows a high-level flow chart of processes utilized by the system 1 of Figure 1.
  • User input at 6 triggers transmission of a message to the remote systems 5.
  • the user for example a technician, accesses the processor 2 that sends the message to the network 3.
  • the message may provide data to the remote system 5 and/or may request information from the remote system 5.
  • the network 3 passes the message to the system interface 4.
  • the system interface 4 receives the message at 9. Additionally, at 9 the system interface 4 accesses the remote systems 5 and delivers the message. If the message is a request for information, then retrieved data is delivered to the user at 11 by sending the message through the network 3 to the processor 2.
  • FIG 3 presents an overview of a preferred architecture of a TechNet system 10 including apparatus and methods for retrieving customer-related data in system, such as legacy systems, in a wireless and/or wireline communications network according to one aspect of this invention.
  • the processor 2 of Figure 1 is preferably a personal computer, and the network 3 is preferably provided by BellSouth.
  • the system interface 4 is preferably an arrangement of servers.
  • Mobile personnel, such as a technician 12 utilize applications on a portable personal computer (PC) 14 to gain access to a BellSouth wireless (BSWD) 16 or wireline network (BSCN) 18.
  • the technician's 12 message can be served from one of two data centers 20, 22 based on the location and access permissions established for the technician 12.
  • An array of individual protocol servers 24, 26 act as agents between the PC 14 and TechNet servers 28, 30.
  • the TechNet servers 28, 30 receive, authenticate, and service user requests, generate legacy systems 5 transactions, receive results from the legacy systems 5 and send results back to the PC 14.
  • the TechNet system 10 and methods carried out by the TechNet system 10 include three main components: (1) the TechNet client PC; (2) the TechNet communications network, including the wireless and wireline network; and (3) the TechNet server.
  • the PC 14 encompasses a TechNet client application that provides a computer interface for TechNet users for allowing remote access to various remote systems, such as legacy systems.
  • the system 10 preferably provides access to LFACS,
  • LMOS low-power MOSF
  • COSMOS COSMOS
  • MLT Low-power MOSF
  • SNECS SNECS
  • MTR OSPCM
  • WASSP WASSP
  • FIG. 4 shows a flow diagram 40 of the TechNet client application.
  • the TechNet client application recognizes a user request, formats it and sends it to the server for processing. On return, the data is received by the TechNet client application, parsed, and displayed to the user.
  • a windows based operating system is utilized as the underlying platform on which the portable PC 14 executes its functionality.
  • Microsoft Windows 95 is the operating system, but this invention is not limited to Microsoft Windows 95.
  • Microsoft Windows 95 provides multi -tasking, memory-allocation, and some error-handling between different components.
  • Microsoft Windows 95 allows dissimilar applications to share data and supports Dynamic Data Exchange (DDE), which allows applications to share data dynamically.
  • DDE Dynamic Data Exchange
  • FIG. 5 shows an overview of a TechNet Communications layer software configuration 42.
  • Figure 5 shows the main software components of the portable PC 14, protocol server 24, 26 and the TechNet server 28, 30. These software components all work together to provide some functionality of the TechNet system 10.
  • the portable PC 14 includes an Itronix PC.
  • Itronix PCs are rugged laptops adapted to include a Motorola radio modem for communicating with the BSWD 16 utilizing a Mobitex protocol, a 33.6 kbps wireline modem for communicating via the BSCN 18 utilizing PPP protocol, Microsoft Windows 95 operating system, TechNet client applications, NetTech middleware software for sending and receiving transactions, and Microsoft Access for providing database access for logging and retrieving data from a client database.
  • Each PC 14 may contain one of the following feature sets: 8.2" monochrome VGA display with BSWD radio modem; 8.2" monochrome VGA display without BSWD radio modem; 10.4" color SVGA display with BSWD radio modem; or 10.4" color SVGA display without BSWD radio modem.
  • the client database stores user and transaction related data, which can be accessed by an administrator in case of a problem or to run client-specific reports. This database primarily logs errors, client performance, and other application related data specific to each client application. Administrators can remotely upload this data to the server on request.
  • a TechNet GUI layer enables the TechNet System 10 to manage the user-to- computer interface, capture user interactions, generate events, present data to the user, assist in the management of the dialog flow, enable the TechNet client PC to collect information from the user, edit it, perform basic validation, and coordinate activities across fields in a window.
  • a TechNet client database stores user and transaction related data that is remotely assessable by an administrator, logs errors, contains client performance related data and application specific data for client applications.
  • the comm layer enables the TechNet client to transparently interact with the TechNet server regardless of the specific physical network employed.
  • the comm server is a Dynamic Link Library (DLL) that utilizes NetTech' s control API to provide access to both the wireless and wireline networks.
  • the control API includes functions for connecting to the network, sending and receiving messages, disconnecting from the network and providing access to information such as radio signal strength and battery power level.
  • the comm server parses the data and adds any information needed from the database to make the message displayable to the PC 14. It also logs any message specific information to the database and then displays the information, providing an audio message to notify the user.
  • the comm server shields an application logic layer from any changes related to the middleware software.
  • a VT100 session provides access to DISC*C, a fiber digital loop carrier system. This session requires a direct connection to a Central Office Terminal (COT), Remote Data Terminal (RDT). or Optical Network Unit (ONU).
  • COT Central Office Terminal
  • RDT Remote Data Terminal
  • ONU Optical Network Unit
  • the TechNet system can be supported by a wireless and a wireline network to provide convenient full coverage to users.
  • the TechNet middleware is software for the protocol server used for transmission of data between client and server.
  • the Middleware can support multiple types of networks (such as RF or land line) and multiple protocols, (e.g. TCP/IP, X25, PPP, etc.).
  • the middleware provides the TechNet System 10 with synchronous as well as asynchronous modes of transmission.
  • the middleware software provides the required network session establishment and management functionality.
  • Middleware software also provides low-level protocol frame recovery, and in some cases provides re-transmission in the event of a local or remote communications failure.
  • a NTFS file system provides system optimization.
  • each of the 15 protocol servers is grouped in a cluster of 3-5 protocol servers that share a NTFS file server located on one of the cluster.
  • the middleware also provides message compression, decompression, and any segmentation required to satisfy protocol or other communication constraints.
  • the middleware software is preferably provided by NetTech.
  • the protocol servers 24, 26 preferably run a Microsoft Windows NT 4.0 workstation operating system that hosts an Remote Messaging API server and RFexpress middleware components.
  • RFexpress server software transmits data from the message queue to both the wireless and wireline networks.
  • a RFexpress instance is required for BSWD and for BSCN.
  • a Tivoli Agent on the protocol server 24, 26 collects information about the current status and performance of the protocol server.
  • the Tivoli Agent exports this data to a Tivoli management station, which is responsible for providing a user interface for viewing this data.
  • a mobility manager enables administrators to monitor statistics from each protocol server 24, 26. These systems provide the required data utilized by the technician to install and maintain services.
  • a comm server component of the TechNet server application is responsible for communications between the TechNet server 28, 30 and the PC 14.
  • a remote messaging API client communicates with remote messaging API server on the protocol server 24, 26. and routes messages in the TechNet system 10.
  • Solaris refers to UNIX Solaris 2.5.1 operation system that runs the TechNet server 28, 30.
  • a message queue is utilized to transmit messages between the TechNet server 28, 30 and the protocol servers 24, 26. The message queue resides on a flat file system on the TechNet host.
  • FIG. 6 shows an overview of the TechNet communications architecture 50.
  • the TechNet communications architecture 50 provides for initiation of connections from a PC 14 through a wireless network and/or a dialup network to the Tech Net server 28,30.
  • the TechNet communications architecture 50 establishes and maintains host connections to the wireless network and provides for re-routing of calls in the event of a failure.
  • the protocol server address is determined using a load-balancing algorithm, preferabh- round robin.
  • a process on the protocol server 24 detects and receives the message (sent from the portable PC 14) via an I/O port, such as but not limited to X.25 or TCP/IP. The process then verifies the sender and receiver information. All the senders, as well as receivers, are registered with the protocol server 24. If the information is valid, the message is placed in the receiver's queue.
  • a message router has a block on the queue activities and recognizes that a new message has arrived. The message router picks the message and places it on one of the sockets 52, 54, 56 of the TechNet Server 28 service I/O ports 58.
  • the preferred process uses load-balancing algorithms to place the message on the queue since there are 25 sockets available per I/O port 58 and one or more ports of the TechNet Server 28 are registered with the protocol servers 24. Therefore, when one of the ports becomes unavailable, the protocol server process places the message on a socket of one of the available ports.
  • TechNet's communication architecture 50 is responsible for all facets of transporting data between the TechNet servers 28, 30 and the portable PC's 14. Middleware 42 is utilized for sending data between remote portable PC's 14 and the centralized TechNet servers 28, 30.
  • TechNet's communications architecture 50 can be grouped into: (1) the wireless network 16; (2) the wireline network 18; and (3) protocol servers 24, 26, and TechNet servers 28, 30 and PCs 14.
  • the Wireless Network Figure 7 shows an embodiment of a BSWD switching network 59.
  • the wireless network is responsible for providing connectivity between the protocol servers 24, 26 and the portable PC's 14 using the BellSouth Wireless Data Mobitex 16 network.
  • the BSWD 16 is a nation-wide public packet-switched wireless network.
  • BSWD 16 is organized in an hierarchical structure, which provides for routing traffic throughout the entire network 59.
  • the actual radio towers 61 are controlled by base stations 62, which are then connected to a local switch 63.
  • the local switches are controlled by regional switches 64, which are then connected to a top level node 65.
  • the entire network 59 is monitored and controlled by network control centers 66.
  • FIG 8 shows a wireless inbound routing configuration 70.
  • the portable PC 14 selects a BSWD tower 72 based on location of the technician 12.
  • the tower 72 connects to a fixed point in the BSWD 16 network.
  • the message switches through the BSWD 16 to an appropriate protocol server 83, 84, 86, 88 selected by BSWD Host Group Address (HGA) to MAN assignment.
  • HGA BSWD Host Group Address
  • the same protocol server 83 is used for the session.
  • the data center initially selected by the HGA address configured on the portable PC 14 is the same protocol server 62 used for the entire session.
  • the comm server 60 of the TechNet 32 server is selected by a queue name used in the send request by the portable PC 14.
  • the technician 12 utilizing his portable PC 14 logs into a protocol server 83 using his current user ID and primary host group address (HGA).
  • HGA specifies the user's designated protocol server 83 group which determines to which data center 78, 80 the user should connect.
  • the BSWD 16 and the middleware 42 coordinate assigning a specific protocol server 83 from within a protocol server array 24, 26 specified by the HGA. Messages sent to the TechNet server 30 are addressed to the specified TechNet Server queue name.
  • Figure 9 shows a wireless outbound routing configuration 90.
  • the TechNet server 30, 32 selects the next available protocol server 83, 84, 86, 88.
  • the middleware 42 transfers the message to the RF express assigned to the user.
  • the protocol server 83 forwards the message to the BSWD 16.
  • BSWD 16 routes the message to the user's last reported location.
  • the portable PC 14 receives the message over the air. Messages sent from the TechNet server 30 to the technician need only be addressed to the specific user ID.
  • the middleware routes messages to the correct protocol server 83 and to the designated user.
  • FIG 10 shows an example of a HGA configuration 100.
  • Each data center 78, 80 has fifteen protocol servers 24, 26 sized to support the entire load of technicians, for example 15,000 technicians 12. Both data centers 78, 80 share a single HGA address.
  • HGA addressing is a networking option that allows for multiple host connections to be addressed by a single address, providing redundancy, which in turn increases reliability and capacity. Every technician 12 can communicate to any of the closest available protocol server 24, 26 by referencing a single HGA address. In the event that all of the protocol servers 24, 26 serving a given local switch fail, HGA routing will automatically send traffic to the next closest group of protocol servers 24, 26. 2. Wireline Network
  • the wireline network is preferably a backup network, but could alternatively be a primary network, responsible for passing data between the protocol servers 24, 26 and portable PC's 14 using dial-up connections.
  • the wireline network portion of the TechNet System 10 architecture provides access in locations that do not have adequate wireless coverage.
  • Wireline provides a highly available and secure dial-up access point for users into BellSouth' s TCP/IP data network.
  • the wireline network furnishes TechNet users with dial-up IP access to the TechNet protocol servers 24, 26 via the Bell System Communications Network (BSCN). Once IP connectivity is established, the flow of traffic between the remote portable PC's 14 and the protocol servers is managed by the middleware resident on the portable PC 14 and the protocol server 24, 26.
  • Figure 11 shows an illustration of wireline inbound routing 102.
  • the technician 12 connects to dial tone and dials a dial-up access number.
  • a modem pool 104 supporting the dial-up access number is selected.
  • the modem pools 104, 106 are connected to a fixed point in the BSCN 18 network.
  • the protocol server 83 selected by an IP address returned from DNS server is the same protocol server 83 used for the entire session.
  • the data center 78 initially selected by the DNS host name configured on the portable PC 14 utilizes the same protocol server 83 for the entire session.
  • the comm server 62 of the TechNet server 28 is selected by the queue name used in the send command from the portable PC 14. Under normal operations, the portable PC 14 logs into a protocol server 83 using the current user's ID and the user's primary protocol server host name.
  • the primary host name is used to specify the user's designated protocol server array 24, 26 in one of two data centers 78, 80.
  • the wireline network and the middleware coordinates the assignment of a specific protocol server 83 from within the protocol server array 24, 26 specified by the host name.
  • Figure 12 shows an illustration of wireline outbound routing 108.
  • the TechNet server 28 selects the next available protocol server.
  • Middleware transfers the message to the RFexpress assigned to the user.
  • the protocol server 83 forwards the message to the user's IP address via the BSCN 18 network.
  • the data center 78 selected by the DNS host name is configured on the portable PC 14.
  • the BSCN and ERS routers direct packets based on destination IP addresses. Ultimately the portable PC 14 receives the message over a dial-up connection.
  • Protocol Servers Messages sent to the TechNet server 28 are addressed to the specified TechNet server queue name. Messages sent from the TechNet server 28 to the remote user 12 need only be addressed to the specific user ID. The middleware 42 routes messages to the correct protocol server 83 and on to the designated user. 3. Protocol Servers
  • Protocol servers 24, 26, 83, 84, 86, 88 are responsible for receiving sending data from/to the wireless 16 and wireline 18 networks and routing that data to the TechNet server 28.
  • Figure 13 shows an illustration of protocol server grouping 110. As shown in Figure 13, preferably an array fifteen individual protocol servers 24, 26 are configured to handle traffic for a data center 78,80, for a total of thirty protocol servers. These thirty protocol servers can handle requests from approximately 15,000 technicians.
  • This invention provides a novel arrangement for providing reliable service and back-up capabilities to such a large number of remote users.
  • the protocol server is implemented using RFexpress middleware from NetTech Systems.
  • the protocol servers 24, 26 are arranged in two separate arrays of individual protocol servers.
  • Figure 14 shows in more detail the architecture of the array of fifteen individual protocol servers 112. This distributed architecture provides for geographical diversity of server sites, as well as diversified routing of traffic.
  • the protocol server architecture 112 allows for distribution of traffic across multiple, lower cost servers and interfaces to the wireless 16 and wireline networks 18.
  • multiple protocol servers provides a greater degree of fault tolerance, since each protocol server 24, as well as the connection to the wireline 16 and wireless 18 networks are redundant.
  • the TechNet protocol servers 24, 26 are primarily intended to conduct the flow of data between the TechNet servers 28, 30 and technicians 12, whether they be connected via wireless 16 or dial-up connections 18.
  • the protocol server middleware 82 also provides the following functions: security, maintains addressing information for remote users, data compression, encryption and key management, network monitoring, and a single queue for outbound messages.
  • the middleware system 42 utilized by the protocol server involves several different software components that cooperate to perform the tasks of the protocol server 83 system.
  • Figure 15 shows an illustration of the protocol server architecture 120 as utilized in the TechNet System 10.
  • the components of the middleware system 42 include the RFexpress 122, 123 server, a remote messaging API server 124, a remote messaging API client 126 and the message queue.
  • the RFexpress server software is responsible for transmitting data from the message queue to both the wireless 16 and wireline 18 networks.
  • a separate instance of RFexpress 122, 123 is required to support each of the external networks, that is, one for the wireless network and one for the wireline network.
  • the remote messaging API server 124 resides on the protocol server 83.
  • the remote messaging API server 124 is responsible for providing communications with the TechNet server 30 via the remote messaging API client 126.
  • the remote messaging API client 126 resides on the TechNet server 30, and is responsible for communicating with the remote messaging API server 124 on the protocol servers 83.
  • a NTFS file server 130 couples to the remote messaging API server 124 and is shared among a cluster of three protocol servers 83 for optimal utilization.
  • a single instance of the remote messaging API client 126 library, with multiple connections to the remote messaging API server 124 on each protocol server 83, provides a single interface for the TechNet 32 server to the protocol server array 24.
  • the remote messaging API server 124 is also responsible for transmitting messages between the remote messaging API client 126 and the message queue.
  • the message queue is used to store all outgoing messages, from the TechNet server 30 to the portable PC 14 until the protocol server 83 responsible for sending the message retrieves it.
  • the message queue resides in a flat file system on the TechNet server 30 host, and is accessible to the protocol servers 83 via NTFS file system client software.
  • Figure 16 shows an illustration of inbound message processing 132.
  • Messages arriving from the wireless 16 and wireline 18 networks are processed as follows.
  • a message from the portable PC 114 remote user is received at the protocol server 83.
  • the message is preferably received via an Eicon X.25 card.
  • the message is preferably received via an Ethernet connection.
  • the RFexpress server 122, 123 responsible for the wireless or wireline network reads the message from the communications network.
  • RFexpress server 122, 123 forwards the message directly to the remote messaging API server 124 on the local protocol server 83.
  • the remote messaging API server 124 transmits the message to the remote messaging API client 126 on the TechNet Server 30.
  • a NTFS file server 130 couples to the remote messaging API server 124 and is shared among a cluster of three protocol servers 83 for optimal utilization.
  • the comm server 60 on the TechNet server 30 receives the message through a call to the remote messaging client library 126.
  • Figure 17 shows an illustration of outbound message processing 134.
  • the comm Server 60 on the TechNet server 30 makes a call to the remote messaging API client library 126, specifying the message to be sent.
  • the remote messaging API client library 126 forwards the request to one of the available remote messaging API servers 124 residing on the protocol server 83.
  • the remote messaging API server 124 places the message in the destination user's directory in the message queue. All thirty instances of the RFexpress 122, 123 server are notified (via named pipe message) that a new outbound message is available.
  • the instance of RFexpress server 122, 123 (residing on one of the other protocol server) that is responsible for the destination user retrieves the message from the message queue.
  • the RFexpress server 122, 123 transmits the message to the remote user, including retries.
  • the message will eventually be either transmitted successfully, or will fail all retries. If the message fails retry attempts, the user is logged off. When the message is successfully delivered the message is deleted from the message queue. A notification of the message status is returned to the TechNet server 30.
  • FIG 18 shows an overview of an arrangement 140 the preferred TechNet server 28, 30 deployment.
  • the TechNet servers 28, 29 come equipped with FDDI 142 and Ethernet cards 144, which allow the TechNet servers 28, 30 to connect to a BellSouth open systems interconnect platform (BOSIP) and the local network in the data centers.
  • BOSIP BellSouth open systems interconnect platform
  • the local network may provide the TechNet server 28, 30 access to the protocol servers 24, 26 (depending on their location in the data center). Support and monitoring systems also need local network access to the TechNet servers 28, 30.
  • FIG 19 shows the TechNet server software configuration 160.
  • Software components include the communications service 60, Transaction Request Broker (TRB) 162, Hands Off Assignment Logic (HAL) 164 database server 166, and report server 168 and Server Environment/Task Routing Interface (SENTRI) 170 and administration server 172.
  • TRB Transaction Request Broker
  • HAL Hands Off Assignment Logic
  • SENTRI Server Environment/Task Routing Interface
  • the TechNet server 28, 30 complexes in both data centers, according to the preferred embodiment has the capacity (I/O, CPU, data storage, etc.) to service the entire field technician work force of about 15,000 technicians 12.
  • the databases between the two TechNet servers 28. 30 are synchronized periodically. This reduces the network traffic and provides an acceptable window for disaster recovery situations.
  • an architecture encompassing more than two TechNet servers 28, 30 is within the scope of this invention. 1.
  • the comm server 60 recognizes the message and places it in the receive queue (store and forward).
  • the comm server 60 is one of the many different processes running on the
  • the comm server 60 has a block on I/O activity of all the sockets of TechNet server's I/O ports 58 connected to the protocol servers 24, 26. Once a message is placed on the socket, the comm server recognizes the message and places in the Receiver queue (store and forward type of message management). 2. Transaction Request Broker
  • TRB 162 Transactional Request Broker process
  • the TRB 162 gets the message from the receive queue and processes it.
  • TRB 162 processes the message, authenticates the user/PC combination, verifies user's logon status, and determines legacy system requests to be initiated for the transaction.
  • TRB accesses a TechNet database, that contains user profile information.
  • TRB 162 makes these requests through predefined contracts to a HAL 164 or directly to the legacy systems 5. All the requests are also logged for administration and management purposes.
  • HAL Hands Off Assignment Logic
  • HAL 164 is a process that provides a screen scraping interface between TRB 162 and legacy systems 5. HAL 164 serves as a shield for TRB 162 against any legacy system changes unrelated to the TechNet system 10. An instance of HAL 164 running on the TechNet servers 28, 30 receives the request from TRB 162 and invokes a legacy system transaction. These transactions can be TN3270 sessions, Navigator contracts or DataKit sessions (depending on the legacy transaction to be invoked).
  • the HAL 164 interface provides information back to the TRB 162 process.
  • the TRB 162 places this information in the send queue, along with sender and receiver information.
  • the comm server 60 picks up the message and places it back on one of the I/O sockets 52, 54, 56. 4. Request completion
  • Request completion utilizes a middleware process that has a clock on the socket 52, 54, 56 I/O activity picks up the message and places it in the sender's queue.
  • Another middleware process determines the destination address of the sender (who initiated the request), and sends the message back to the portable PC 14 via the communications network 16, 18.
  • the portable PC 14 receives the message and displays the results to the user.
  • the Administration Server 172 (also called the GUI-Server Agent GSA) is a web-based server process that provides remote access to TechNet System administrators. This system consists of technician data required by TechNet applications and the tools necessary to maintain the data and produce reports.
  • the TechNet Administrators can use a web browser to access JAVA applets to perform administrative services.
  • This process has access to the various databases, flat files, and monitoring processes maintained by the TechNet system.
  • the TechNet System 10 can maintain user profiles having access authorization and logs transactions for performance and auditing purposes.
  • the database server 166 is one of the processes running on the TechNet server 28, 30 and provides access to the database.
  • the report server 168 collects any return data needed for selected reports.
  • Server Environment/Task Routing Interface (SENTRI) 170 is a process controller. SENTRI becomes active at boot time and monitors all the other server processes. It logs process activities and restarts a troubled processes. 8. Terminal Emulation
  • Terminal emulation provides a unique emulation and/or screen scraper function that shields the system from interface changes made to a legacy system.
  • Traditional emulation and screen scrapers serve to mimic functions that would be performed by a user directly accessing a particular system. This function can limit a systems capability by requiring constant updating if the look and feel of the interface changes.
  • this invention provides a separate and distinct interface to certain legacy systems that avoids having to change each time an interface changes. 9. Navigator
  • the system preferably provides a more direct connection to certain legacy and other remote systems.
  • the system preferably connects to LMOS and OPSCM through Navigator 171 that allows an efficient, effective access to LMOS and OPSCM without concern for changes to legacy Systems.
  • the Navigator tool kit provides a messaging service delivering blocks of LMOS data to the TechNet server 28, 30.
  • customer premises work involves dispatching to correct troubles and to complete service orders.
  • Navigator 171 access to LMOS increases technician's ability to efficiently perform job duties.
  • Figure 21 shows a representative example of TechNet Server components in each data center. Any equivalent component can be substituted for any of the above listed components listed in Figure 21.
  • this invention will provide the described capabilities to technicians and the following enhancement features: immediate input and close-out of customer service requests; capture of customer signatures electronically; acceptance of credit card payments for installation of new services or repairs; automation of monthly mileage reports and motor vehicle repair requests; ordering materials and supplies; capabilities for technicians to train themselves on new services and procedures using a CD-ROM disk; access to e-mail, network construction data, and cable planning documents; and printing out a customer statement for services rendered, product information, job aids, customer instructions on the features and services installed and access an intranet.
  • An advantage of this invention is that it provides technicians with remote access to remote systems such as legacy systems via a wireless communications network.

Abstract

Methods and systems provide a mobile workforce remote access to legacy systems utilizing a wireless communications network with a wireline network available as a backup network. This system includes portable personal computers in communication with the wireless or wireline communications network, protocol servers for receiving and forwarding messages to and from the portable personal computers, and an interface in communications with the protocol servers and legacy systems.

Description

SYSTEMS AND METHODS FOR UTILIZING A COMMUNICATIONS NETWORK FOR PROVIDING MOBILE USERS ACCESS TO LEGACY
SYSTEMS
Related Applications
This application claims priority to Provisional Application No. 60/091,373 filed July 1, 1998 entitled. "System and Method for Providing Access to Legacy Systems," which is incorporated by reference herein. Field of the Invention The present invention relates in general to the field of telecommunications dispatching systems and in particular to the field of wireless and wireline communications providing mobile personnel access to legacy systems and other remote systems.
BACKGROUND OF THE INVENTION Telecommunications technicians perform a variety of functions for telecommunications companies. Among the critical functions they serve includes providing on-site installation and maintenance service support to customers. While on the customer's premises and when preparing for a customer visit, mobile personnel such as technicians need access to a variety of data, and systems such as, facility assignments, network testing functions, maintenance processes and procedures and customer specific information. Typically, the remote systems provide access to systems such as dispatch, facilities, and billing systems.
Regularly, technicians receive job assignments, travel to the customer's location, and complete the assignment. To effectively complete their job duties, technicians utilize computers to remotely access the required databases. Normally, the technicians remotely access the legacy systems to retrieve the necessary information. For the Regional Bell Operating Companies (RBOC), the legacy systems include a collection of databases established by the Bell System and currently managed by BellCore provide critical information necessary for technicians to complete their job duties.
Currently, RBOC installation and maintenance technicians access the legacy systems necessary to perform job tasks through the Craft Access System (CAS) gateway. CAS provides technicians with the capability to remotely access operations systems while at the customer's premise performing work activities such as installation and maintenance of facilities. The primary operations functions accessible to a technician on the CAS network include receiving new work assignments, information on current work assignment, facility testing, and electronic mail.
CAS provides access to many of these functions though a variety of legacy systems. Legacy systems include Loop Facility Assignment Control System (LFACS), Loop Maintenance Operations System (LMOS), Computer System for Main Frame Operations (COSMOS). Mechanized Loop Testing (MLT), Secure Network Element Contract Server (SNECS), Mechanized Time Reporting (MTR), OutSide Plant Construction Management (OPSCM) and Work Activity Statistical Sampling Plan (WASSP). Each of these systems provides vital data to technicians.
LFACS, a part of the Facility Assignment and Control System (FACS) is primarily responsible for completing outside plant facility assignments. COSMOS provides methods to effective manage, control and utilize main central office distributing frame facilities and circuits. This is accomplished by automating the assignment of central office equipment, telephone numbers, and frame cross connections. A selected sample of outside plant technicians are selected each month to utilize WASSP to report how much time they spend doing different tasks on each job they complete. This data is verified and sent to the MTR system.
LMOS is further delineated into LMOS Host and LMOS Front End (FE). LMOS Host stores and maintains detailed line record information. It also creates and maintains historical data on closed trouble reports. LMOS FE provided mechanized methods of maintaining customer line records and mechanized capability for entering, processing and tracking trouble reports. MLT is an automated loop testing system available through LMOS FE. It is used to test loops equipped with one-party and commercial services such as Private Branch Exchange (PBX) and Central Office Centrex. SNEC is a security interface. OPSCM is designed to manage outside plant construction from end to end. It encompasses contracts, contractors, job management, complaints, billing and payments, and informational reporting. These systems provide the required data utilized by technicians to install and maintain services. While CAS provides access to legacy systems, CAS has limitations. CAS is a
Lucent Technologies proprietary system, which in some versions is expected to be unable to function beyond the year 2000. CAS requires technicians to use a dial-up connection to access the information systems they need to perform their job, requiring them to find dial tone. Currently, technicians access CAS utilizing Computer Access Terminals (CATs), also referred to as "the brick". CATs require technicians to use a dial-up connection to transmit data at 1.2 kbps. This process restricts the technicians mobility while using the system. The technician must either gain permission of a customer to tie up their phone line or leave the customer premise, drive to a location where the technician can plug in a computer terminal and log in. Technicians are placed in the position of either tying up a customer's phone or driving to find dial tone. Both are inefficient methods of communicating with the network.
Moreover, after finding dial tone, logging into CAS takes appropriately three minutes. Additionally closing a service order with a CAT takes at least five minutes. Viewing a record on line with the CAT could take more than five minutes. In other words, CATs are slow. CATs are DOS based script orient computers with no memory, i.e. it is a dumb terminal. Only a single task is available at a time utilizing CAT.
Further, with CAS a technician can only download information on four facility pairs available to the customer. If all four pairs are not working, the technician cannot complete the customer's order.
Moreover, access to LMOS through CAS is cumbersome. LMOS provides critical customer information and serves as a tracking mechanism for trouble reports and expectedly, technicians frequently access LMOS. Currently, at the server ends of the CAS system, each LMOS request is processed separately resulting in large amounts of traffic across the network requesting access to LMOS thereby burdening the network.
SUMMARY OF THE INVENTION The present invention addresses the problems associated with CAS technician dispatch systems and provides additional capabilities and features not available utilizing CAS. The methods and systems of this invention provide for a Year 2000 compliant distributed client-server application for mobile personnel with reliable and secure access to remote systems, such as legacy systems. The preferred system associated with this invention for discussion purposes will be referred to in a non-limiting manner as TechNet. Generally, the TechNet system includes portable personal computers in communication with a wireless or wireline communications network, protocol servers for receiving and forwarding messages to and from the portable personal computers, the protocol servers in communications with a TechNet server in communications with legacy systems and other remote systems.
In the preferred embodiment, the technicians are equipped with ruggedized notebook computers that provide two-way wireless and wireline communication. Data can be transmitted up to 33.6 kbps via wireline connections and up to 8 kbps wirelessly. Wireless service utilized by the technicians to connect to the TechNet servers is preferably through the BellSouth Wireless Data Network (BSWD) although other wireless networks may be used. Wireline service or dial-up service utilized by the technicians to connect to the TechNet servers is through the BellSouth Communications Network (BSCN) but again other wireline networks may be used.
Protocol servers, preferably manufactured by NetTech, provide protocol conversion and middleware service in the TechNet system.
The TechNet server provides for receiving user requests, authenticating user access, servicing user requests, generating legacy system transactions, providing an interface and emulation to legacy systems, receiving results from the legacy systems and sending results back to the users portable PC. Legacy systems contemplated as part of this invention for RBOCs include but are not limited to, Loop Facility Assignment Control System (LFACS), Loop Maintenance Operations System (LMOS), Computer System for Main Frame Operations (COSMOS), Mechanized Loop Testing (MLT), Secure Network Element Contract Server (SNECS), Mechanized Time Reporting (MTR), and Work Activity Statistical Sampling Plan (WASSP).
Using a system which employs wireless technology will enable technicians to perform job tasks with a greater degree of mobility, and a time savings over the previous systems, beyond the end of the century. A ruggedized laptop personal computer provides a flexible platform which enables future improvements in information systems and allows the technician to provide better service to customers. Objects of this invention include:
To provide users in the field providing customer service with access to remote systems, such as legacy systems.
To provide technicians with a system for receiving and closing out trouble tickets, work orders, testing, identification and repair of customer lines. To provide a dispatch system that is Year 2000 compliant. To provide a dispatch system that provides for immediate input and close-out of customer service requests.
To provide a dispatch system having wireless access to legacy and other remote systems.
To provide technicians with high speed access to legacy and other remote systems. To provide technicians a windows based interface with remote access to legacy and other systems.
To provide a more efficient method for processing messages and inquiries into remote systems.
Other objects, features and advantages of this invention will be set forth in part in the description which follows and in part will be obvious from the description or may be learned by practice of the invention. The objects, features and advantages of this invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims.
BRTEF DESCRIPTION OF THE DRAWINGS Figure 1 presents a broad overview of a system 1 for providing personnel remote access to legacy systems in accordance with a preferred embodiment of this invention.
Figure 2 shows a high-level flow chart of the processes utilized by the system 1 of Figure 1.
Figure 3 shows an overview diagram of an architecture of a TechNet system according to a preferred embodiment of this invention.
Figure 4 shows a flow diagram of a TechNet client application. Figure 5 shows an overview of the TechNet communications layer software configuration. Figure 6 shows a diagram of an architecture including a TechNet portable PC in communication with a protocol server utilizing a communications network.
Figure 7 shows an embodiment of the BellSouth Wireless network (BSWD) switching network. Figure 8 shows a wireless inbound routing configuration.
Figure 9 shows a wireless outbound routing configuration. Figure 10 shows an example of a Host Group Addressing (HGA) configuration. Figure 11 shows a wireline inbound routing configuration. Figure 12 shows a wireline outbound routing configuration. Figure 13 shows an illustration of protocol server grouping.
Figure 14 shows a more detailed view of a configuration of the array of protocol servers of Figure 13.
Figure 15 shows an illustration of the protocol server architecture. Figure 16 shows an illustration of inbound message processing utilizing the protocol server architecture of Figure 14.
Figure 17 shows an illustration of outbound message processing utilizing the protocol server architecture of Figure 14.
Figure 18 shows an overview of an arrangement of TechNet servers deployment. Figure 19 shows an illustration of a TechNet server software configuration. Figure 20 shows a flow diagram of a Hands Off Assignment Logic (HAL) interface to legacy systems.
Figure 21 shows an example of TechNet server components utilized in each data center.
DETAILED DESCRIPTION OF THE INVENTION Reference will now be made in detail to preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
I. Overview of Svstems and Methods This invention includes systems and methods for providing personnel, such as technicians, with processors capable of remotely accessing legacy systems and other remote systems over a communications network. The communications network may include a wireless network and a wireline network available as a backup network when personnel are unable to utilize the wireless network. Moreover, the communications network includes a variety of networks, for instance local, long distance, and cable networks.
The systems and methods disclosed are not limited to local telecommunications company applications. Providing remote access to databases for other service providers such as cable providers, utility companies, internet service providers, wireless network providers, and long distance companies, that provision and maintain, for example, coaxial cable, fiber optic cables and copper facilities is within the scope of this invention. II. Overview of Svstem
Figure 1 presents a broad overview of a system 1 for providing personnel, such as a mobile workforce, access to remote systems in accordance with a preferred embodiment of the invention. The system 1 includes a processor 2, a communications network 3, a system interface 4, a network 3 A and remote systems 5.
Figure 2 shows a high-level flow chart of processes utilized by the system 1 of Figure 1. User input at 6 triggers transmission of a message to the remote systems 5. The user, for example a technician, accesses the processor 2 that sends the message to the network 3. The message may provide data to the remote system 5 and/or may request information from the remote system 5. At 8, the network 3 passes the message to the system interface 4. The system interface 4 receives the message at 9. Additionally, at 9 the system interface 4 accesses the remote systems 5 and delivers the message. If the message is a request for information, then retrieved data is delivered to the user at 11 by sending the message through the network 3 to the processor 2. III. Preferred Svstem Overview
Figure 3 presents an overview of a preferred architecture of a TechNet system 10 including apparatus and methods for retrieving customer-related data in system, such as legacy systems, in a wireless and/or wireline communications network according to one aspect of this invention. The processor 2 of Figure 1 is preferably a personal computer, and the network 3 is preferably provided by BellSouth. The system interface 4 is preferably an arrangement of servers. Mobile personnel, such as a technician 12 utilize applications on a portable personal computer (PC) 14 to gain access to a BellSouth wireless (BSWD) 16 or wireline network (BSCN) 18. In a preferred embodiment, the technician's 12 message can be served from one of two data centers 20, 22 based on the location and access permissions established for the technician 12. An array of individual protocol servers 24, 26 act as agents between the PC 14 and TechNet servers 28, 30. The TechNet servers 28, 30 receive, authenticate, and service user requests, generate legacy systems 5 transactions, receive results from the legacy systems 5 and send results back to the PC 14. The TechNet system 10 and methods carried out by the TechNet system 10 include three main components: (1) the TechNet client PC; (2) the TechNet communications network, including the wireless and wireline network; and (3) the TechNet server. A. TechNet Client PC
The PC 14 encompasses a TechNet client application that provides a computer interface for TechNet users for allowing remote access to various remote systems, such as legacy systems. For an RBOC, the system 10 preferably provides access to LFACS,
LMOS, COSMOS, MLT, SNECS, MTR, OSPCM and WASSP. It should be understood that the system 10 is not limited to these remote systems but that access may be provided to other legacy systems and to non-legacy systems.
Figure 4 shows a flow diagram 40 of the TechNet client application. The TechNet client application recognizes a user request, formats it and sends it to the server for processing. On return, the data is received by the TechNet client application, parsed, and displayed to the user. A windows based operating system, is utilized as the underlying platform on which the portable PC 14 executes its functionality. Preferably, Microsoft Windows 95 is the operating system, but this invention is not limited to Microsoft Windows 95. Microsoft Windows 95 provides multi -tasking, memory-allocation, and some error-handling between different components. Microsoft Windows 95 allows dissimilar applications to share data and supports Dynamic Data Exchange (DDE), which allows applications to share data dynamically.
Figure 5 shows an overview of a TechNet Communications layer software configuration 42. Figure 5 shows the main software components of the portable PC 14, protocol server 24, 26 and the TechNet server 28, 30. These software components all work together to provide some functionality of the TechNet system 10.
In a preferred embodiment, the portable PC 14 includes an Itronix PC. Itronix PCs are rugged laptops adapted to include a Motorola radio modem for communicating with the BSWD 16 utilizing a Mobitex protocol, a 33.6 kbps wireline modem for communicating via the BSCN 18 utilizing PPP protocol, Microsoft Windows 95 operating system, TechNet client applications, NetTech middleware software for sending and receiving transactions, and Microsoft Access for providing database access for logging and retrieving data from a client database. Each PC 14 may contain one of the following feature sets: 8.2" monochrome VGA display with BSWD radio modem; 8.2" monochrome VGA display without BSWD radio modem; 10.4" color SVGA display with BSWD radio modem; or 10.4" color SVGA display without BSWD radio modem. In one application of the invention, approximately 15,000 technicians 12 will be deployed each utilizing a portable PC 14 on the TechNet system 10. The client database stores user and transaction related data, which can be accessed by an administrator in case of a problem or to run client-specific reports. This database primarily logs errors, client performance, and other application related data specific to each client application. Administrators can remotely upload this data to the server on request.
A TechNet GUI layer enables the TechNet System 10 to manage the user-to- computer interface, capture user interactions, generate events, present data to the user, assist in the management of the dialog flow, enable the TechNet client PC to collect information from the user, edit it, perform basic validation, and coordinate activities across fields in a window. A TechNet client database stores user and transaction related data that is remotely assessable by an administrator, logs errors, contains client performance related data and application specific data for client applications. The comm layer enables the TechNet client to transparently interact with the TechNet server regardless of the specific physical network employed.
Once parsed by the TechNet client, the message is sent to the comm layer to be sent to the TechNet server. The PC's 14 comm server module handles communications with the TechNet server 28, 30. The comm server is a Dynamic Link Library (DLL) that utilizes NetTech' s control API to provide access to both the wireless and wireline networks. The control API includes functions for connecting to the network, sending and receiving messages, disconnecting from the network and providing access to information such as radio signal strength and battery power level. On return, when the TechNet server sends data to the TechNet client, the comm server parses the data and adds any information needed from the database to make the message displayable to the PC 14. It also logs any message specific information to the database and then displays the information, providing an audio message to notify the user. The comm server shields an application logic layer from any changes related to the middleware software.
A VT100 session provides access to DISC*C, a fiber digital loop carrier system. This session requires a direct connection to a Central Office Terminal (COT), Remote Data Terminal (RDT). or Optical Network Unit (ONU).
The TechNet system can be supported by a wireless and a wireline network to provide convenient full coverage to users.
The TechNet middleware is software for the protocol server used for transmission of data between client and server. The Middleware can support multiple types of networks (such as RF or land line) and multiple protocols, (e.g. TCP/IP, X25, PPP, etc.). The middleware provides the TechNet System 10 with synchronous as well as asynchronous modes of transmission. The middleware software provides the required network session establishment and management functionality. Middleware software also provides low-level protocol frame recovery, and in some cases provides re-transmission in the event of a local or remote communications failure. A NTFS file system provides system optimization. Preferably, each of the 15 protocol servers is grouped in a cluster of 3-5 protocol servers that share a NTFS file server located on one of the cluster. Additionally, the middleware also provides message compression, decompression, and any segmentation required to satisfy protocol or other communication constraints. The middleware software is preferably provided by NetTech.
The protocol servers 24, 26 preferably run a Microsoft Windows NT 4.0 workstation operating system that hosts an Remote Messaging API server and RFexpress middleware components. RFexpress server software transmits data from the message queue to both the wireless and wireline networks. A RFexpress instance is required for BSWD and for BSCN. A Tivoli Agent on the protocol server 24, 26 collects information about the current status and performance of the protocol server. The Tivoli Agent exports this data to a Tivoli management station, which is responsible for providing a user interface for viewing this data. A mobility manager enables administrators to monitor statistics from each protocol server 24, 26. These systems provide the required data utilized by the technician to install and maintain services. A comm server component of the TechNet server application is responsible for communications between the TechNet server 28, 30 and the PC 14. A remote messaging API client communicates with remote messaging API server on the protocol server 24, 26. and routes messages in the TechNet system 10. Solaris refers to UNIX Solaris 2.5.1 operation system that runs the TechNet server 28, 30. A message queue is utilized to transmit messages between the TechNet server 28, 30 and the protocol servers 24, 26. The message queue resides on a flat file system on the TechNet host. B. TechNet Communications Architecture
Figure 6 shows an overview of the TechNet communications architecture 50. The TechNet communications architecture 50 provides for initiation of connections from a PC 14 through a wireless network and/or a dialup network to the Tech Net server 28,30. The TechNet communications architecture 50 establishes and maintains host connections to the wireless network and provides for re-routing of calls in the event of a failure.
In operation, the protocol server address is determined using a load-balancing algorithm, preferabh- round robin. On message arrival, a process on the protocol server 24 detects and receives the message (sent from the portable PC 14) via an I/O port, such as but not limited to X.25 or TCP/IP. The process then verifies the sender and receiver information. All the senders, as well as receivers, are registered with the protocol server 24. If the information is valid, the message is placed in the receiver's queue. In another process, a message router has a block on the queue activities and recognizes that a new message has arrived. The message router picks the message and places it on one of the sockets 52, 54, 56 of the TechNet Server 28 service I/O ports 58.
The preferred process uses load-balancing algorithms to place the message on the queue since there are 25 sockets available per I/O port 58 and one or more ports of the TechNet Server 28 are registered with the protocol servers 24. Therefore, when one of the ports becomes unavailable, the protocol server process places the message on a socket of one of the available ports.
TechNet's communication architecture 50 is responsible for all facets of transporting data between the TechNet servers 28, 30 and the portable PC's 14. Middleware 42 is utilized for sending data between remote portable PC's 14 and the centralized TechNet servers 28, 30. TechNet's communications architecture 50 can be grouped into: (1) the wireless network 16; (2) the wireline network 18; and (3) protocol servers 24, 26, and TechNet servers 28, 30 and PCs 14. 1. Wireless Network Figure 7 shows an embodiment of a BSWD switching network 59. The wireless network is responsible for providing connectivity between the protocol servers 24, 26 and the portable PC's 14 using the BellSouth Wireless Data Mobitex 16 network. The BSWD 16 is a nation-wide public packet-switched wireless network. BSWD 16 is organized in an hierarchical structure, which provides for routing traffic throughout the entire network 59. The actual radio towers 61 are controlled by base stations 62, which are then connected to a local switch 63. The local switches are controlled by regional switches 64, which are then connected to a top level node 65. The entire network 59 is monitored and controlled by network control centers 66.
Figure 8 shows a wireless inbound routing configuration 70. The portable PC 14 selects a BSWD tower 72 based on location of the technician 12. The tower 72 connects to a fixed point in the BSWD 16 network. The message switches through the BSWD 16 to an appropriate protocol server 83, 84, 86, 88 selected by BSWD Host Group Address (HGA) to MAN assignment. Once selected, the same protocol server 83 is used for the session. Likewise, the data center initially selected by the HGA address configured on the portable PC 14 is the same protocol server 62 used for the entire session. The comm server 60 of the TechNet 32 server is selected by a queue name used in the send request by the portable PC 14.
The technician 12 utilizing his portable PC 14 logs into a protocol server 83 using his current user ID and primary host group address (HGA). The HGA specifies the user's designated protocol server 83 group which determines to which data center 78, 80 the user should connect. The BSWD 16 and the middleware 42 coordinate assigning a specific protocol server 83 from within a protocol server array 24, 26 specified by the HGA. Messages sent to the TechNet server 30 are addressed to the specified TechNet Server queue name.
Figure 9 shows a wireless outbound routing configuration 90. The TechNet server 30, 32 selects the next available protocol server 83, 84, 86, 88. The middleware 42 transfers the message to the RF express assigned to the user. The protocol server 83 forwards the message to the BSWD 16. BSWD 16 routes the message to the user's last reported location. The portable PC 14 receives the message over the air. Messages sent from the TechNet server 30 to the technician need only be addressed to the specific user ID. The middleware routes messages to the correct protocol server 83 and to the designated user.
Figure 10 shows an example of a HGA configuration 100. Each data center 78, 80 has fifteen protocol servers 24, 26 sized to support the entire load of technicians, for example 15,000 technicians 12. Both data centers 78, 80 share a single HGA address. HGA addressing is a networking option that allows for multiple host connections to be addressed by a single address, providing redundancy, which in turn increases reliability and capacity. Every technician 12 can communicate to any of the closest available protocol server 24, 26 by referencing a single HGA address. In the event that all of the protocol servers 24, 26 serving a given local switch fail, HGA routing will automatically send traffic to the next closest group of protocol servers 24, 26. 2. Wireline Network
The wireline network is preferably a backup network, but could alternatively be a primary network, responsible for passing data between the protocol servers 24, 26 and portable PC's 14 using dial-up connections. The wireline network portion of the TechNet System 10 architecture provides access in locations that do not have adequate wireless coverage. Wireline provides a highly available and secure dial-up access point for users into BellSouth' s TCP/IP data network. The wireline network furnishes TechNet users with dial-up IP access to the TechNet protocol servers 24, 26 via the Bell System Communications Network (BSCN). Once IP connectivity is established, the flow of traffic between the remote portable PC's 14 and the protocol servers is managed by the middleware resident on the portable PC 14 and the protocol server 24, 26. Figure 11 shows an illustration of wireline inbound routing 102. The technician 12 connects to dial tone and dials a dial-up access number. A modem pool 104 supporting the dial-up access number is selected. The modem pools 104, 106 are connected to a fixed point in the BSCN 18 network. The protocol server 83 selected by an IP address returned from DNS server is the same protocol server 83 used for the entire session. Likewise, the data center 78 initially selected by the DNS host name configured on the portable PC 14 utilizes the same protocol server 83 for the entire session. The comm server 62 of the TechNet server 28 is selected by the queue name used in the send command from the portable PC 14. Under normal operations, the portable PC 14 logs into a protocol server 83 using the current user's ID and the user's primary protocol server host name. The primary host name is used to specify the user's designated protocol server array 24, 26 in one of two data centers 78, 80. The wireline network and the middleware coordinates the assignment of a specific protocol server 83 from within the protocol server array 24, 26 specified by the host name. Figure 12 shows an illustration of wireline outbound routing 108. The TechNet server 28 selects the next available protocol server. Middleware transfers the message to the RFexpress assigned to the user. The protocol server 83 forwards the message to the user's IP address via the BSCN 18 network. The data center 78 selected by the DNS host name is configured on the portable PC 14. The BSCN and ERS routers direct packets based on destination IP addresses. Ultimately the portable PC 14 receives the message over a dial-up connection. Messages sent to the TechNet server 28 are addressed to the specified TechNet server queue name. Messages sent from the TechNet server 28 to the remote user 12 need only be addressed to the specific user ID. The middleware 42 routes messages to the correct protocol server 83 and on to the designated user. 3. Protocol Servers
Protocol servers 24, 26, 83, 84, 86, 88 are responsible for receiving sending data from/to the wireless 16 and wireline 18 networks and routing that data to the TechNet server 28. Figure 13 shows an illustration of protocol server grouping 110. As shown in Figure 13, preferably an array fifteen individual protocol servers 24, 26 are configured to handle traffic for a data center 78,80, for a total of thirty protocol servers. These thirty protocol servers can handle requests from approximately 15,000 technicians. This invention provides a novel arrangement for providing reliable service and back-up capabilities to such a large number of remote users. The protocol server is implemented using RFexpress middleware from NetTech Systems.
The protocol servers 24, 26 are arranged in two separate arrays of individual protocol servers. Figure 14 shows in more detail the architecture of the array of fifteen individual protocol servers 112. This distributed architecture provides for geographical diversity of server sites, as well as diversified routing of traffic. The protocol server architecture 112, allows for distribution of traffic across multiple, lower cost servers and interfaces to the wireless 16 and wireline networks 18. In addition, multiple protocol servers provides a greater degree of fault tolerance, since each protocol server 24, as well as the connection to the wireline 16 and wireless 18 networks are redundant.
The TechNet protocol servers 24, 26 are primarily intended to conduct the flow of data between the TechNet servers 28, 30 and technicians 12, whether they be connected via wireless 16 or dial-up connections 18. Along with this primary function, the protocol server middleware 82 also provides the following functions: security, maintains addressing information for remote users, data compression, encryption and key management, network monitoring, and a single queue for outbound messages.
The middleware system 42 utilized by the protocol server involves several different software components that cooperate to perform the tasks of the protocol server 83 system. Figure 15 shows an illustration of the protocol server architecture 120 as utilized in the TechNet System 10. The components of the middleware system 42 include the RFexpress 122, 123 server, a remote messaging API server 124, a remote messaging API client 126 and the message queue.
The RFexpress server software is responsible for transmitting data from the message queue to both the wireless 16 and wireline 18 networks. A separate instance of RFexpress 122, 123 is required to support each of the external networks, that is, one for the wireless network and one for the wireline network.
The remote messaging API server 124 resides on the protocol server 83. The remote messaging API server 124 is responsible for providing communications with the TechNet server 30 via the remote messaging API client 126. The remote messaging API client 126 resides on the TechNet server 30, and is responsible for communicating with the remote messaging API server 124 on the protocol servers 83. A NTFS file server 130 couples to the remote messaging API server 124 and is shared among a cluster of three protocol servers 83 for optimal utilization. A single instance of the remote messaging API client 126 library, with multiple connections to the remote messaging API server 124 on each protocol server 83, provides a single interface for the TechNet 32 server to the protocol server array 24. The remote messaging API server 124 is also responsible for transmitting messages between the remote messaging API client 126 and the message queue.
The message queue is used to store all outgoing messages, from the TechNet server 30 to the portable PC 14 until the protocol server 83 responsible for sending the message retrieves it. The message queue resides in a flat file system on the TechNet server 30 host, and is accessible to the protocol servers 83 via NTFS file system client software.
Figure 16 shows an illustration of inbound message processing 132. Messages arriving from the wireless 16 and wireline 18 networks are processed as follows. A message from the portable PC 114 remote user is received at the protocol server 83. For wireless messages, the message is preferably received via an Eicon X.25 card. For wireline messages, for example, the message is preferably received via an Ethernet connection. The RFexpress server 122, 123 responsible for the wireless or wireline network reads the message from the communications network. RFexpress server 122, 123 forwards the message directly to the remote messaging API server 124 on the local protocol server 83. The remote messaging API server 124 transmits the message to the remote messaging API client 126 on the TechNet Server 30. A NTFS file server 130 couples to the remote messaging API server 124 and is shared among a cluster of three protocol servers 83 for optimal utilization. The comm server 60 on the TechNet server 30 receives the message through a call to the remote messaging client library 126.
Figure 17 shows an illustration of outbound message processing 134. The comm Server 60 on the TechNet server 30 makes a call to the remote messaging API client library 126, specifying the message to be sent. The remote messaging API client library 126 forwards the request to one of the available remote messaging API servers 124 residing on the protocol server 83. The remote messaging API server 124 places the message in the destination user's directory in the message queue. All thirty instances of the RFexpress 122, 123 server are notified (via named pipe message) that a new outbound message is available. The instance of RFexpress server 122, 123 (residing on one of the other protocol server) that is responsible for the destination user retrieves the message from the message queue. The RFexpress server 122, 123 transmits the message to the remote user, including retries. The message will eventually be either transmitted successfully, or will fail all retries. If the message fails retry attempts, the user is logged off. When the message is successfully delivered the message is deleted from the message queue. A notification of the message status is returned to the TechNet server 30. C. TechNet Server
Figure 18 shows an overview of an arrangement 140 the preferred TechNet server 28, 30 deployment. The TechNet servers 28, 29 come equipped with FDDI 142 and Ethernet cards 144, which allow the TechNet servers 28, 30 to connect to a BellSouth open systems interconnect platform (BOSIP) and the local network in the data centers. BOSIP, a communications link to the legacy systems, provides a backbone TCP/IP network. The local network may provide the TechNet server 28, 30 access to the protocol servers 24, 26 (depending on their location in the data center). Support and monitoring systems also need local network access to the TechNet servers 28, 30.
Figure 19 shows the TechNet server software configuration 160. Software components include the communications service 60, Transaction Request Broker (TRB) 162, Hands Off Assignment Logic (HAL) 164 database server 166, and report server 168 and Server Environment/Task Routing Interface (SENTRI) 170 and administration server 172.
The TechNet server 28, 30 complexes in both data centers, according to the preferred embodiment has the capacity (I/O, CPU, data storage, etc.) to service the entire field technician work force of about 15,000 technicians 12. The databases between the two TechNet servers 28. 30 are synchronized periodically. This reduces the network traffic and provides an acceptable window for disaster recovery situations. Alternatively, an architecture encompassing more than two TechNet servers 28, 30 is within the scope of this invention. 1. Communications server
Once a message is placed in a socket of the TechNet server's Input/Output (I/O) port 58 the comm server 60 recognizes the message and places it in the receive queue (store and forward). The comm server 60 is one of the many different processes running on the
TechNet servers 28, 30. The comm server 60 has a block on I/O activity of all the sockets of TechNet server's I/O ports 58 connected to the protocol servers 24, 26. Once a message is placed on the socket, the comm server recognizes the message and places in the Receiver queue (store and forward type of message management). 2. Transaction Request Broker
Most of the business logic related to the system server resides on the Transactional Request Broker process (TRB) 162. The TRB 162 gets the message from the receive queue and processes it. TRB 162 processes the message, authenticates the user/PC combination, verifies user's logon status, and determines legacy system requests to be initiated for the transaction. For user authentication, TRB accesses a TechNet database, that contains user profile information. Further, TRB 162 makes these requests through predefined contracts to a HAL 164 or directly to the legacy systems 5. All the requests are also logged for administration and management purposes. 3. Hands Off Assignment Logic Figure 20 shows a flow diagram of a Hands Off Assignment Logic (HAL) 164 interface to legacy systems 5. HAL 164 is a process that provides a screen scraping interface between TRB 162 and legacy systems 5. HAL 164 serves as a shield for TRB 162 against any legacy system changes unrelated to the TechNet system 10. An instance of HAL 164 running on the TechNet servers 28, 30 receives the request from TRB 162 and invokes a legacy system transaction. These transactions can be TN3270 sessions, Navigator contracts or DataKit sessions (depending on the legacy transaction to be invoked).
Once the request has been completed, the HAL 164 interface provides information back to the TRB 162 process. The TRB 162 places this information in the send queue, along with sender and receiver information. The comm server 60 picks up the message and places it back on one of the I/O sockets 52, 54, 56. 4. Request completion
Request completion utilizes a middleware process that has a clock on the socket 52, 54, 56 I/O activity picks up the message and places it in the sender's queue. Another middleware process determines the destination address of the sender (who initiated the request), and sends the message back to the portable PC 14 via the communications network 16, 18. The portable PC 14 receives the message and displays the results to the user.
5. Administration server
The Administration Server 172 (Admin Server), (also called the GUI-Server Agent GSA) is a web-based server process that provides remote access to TechNet System administrators. This system consists of technician data required by TechNet applications and the tools necessary to maintain the data and produce reports.
Through this process, the TechNet Administrators can use a web browser to access JAVA applets to perform administrative services. This process has access to the various databases, flat files, and monitoring processes maintained by the TechNet system.
6. Data Base server and report server
The TechNet System 10 can maintain user profiles having access authorization and logs transactions for performance and auditing purposes. The database server 166 is one of the processes running on the TechNet server 28, 30 and provides access to the database. The report server 168 collects any return data needed for selected reports.
7. Server Environment/Task Routing Interface.
Server Environment/Task Routing Interface (SENTRI) 170 is a process controller. SENTRI becomes active at boot time and monitors all the other server processes. It logs process activities and restarts a troubled processes. 8. Terminal Emulation
Terminal emulation provides a unique emulation and/or screen scraper function that shields the system from interface changes made to a legacy system. Traditional emulation and screen scrapers serve to mimic functions that would be performed by a user directly accessing a particular system. This function can limit a systems capability by requiring constant updating if the look and feel of the interface changes. Thus, this invention provides a separate and distinct interface to certain legacy systems that avoids having to change each time an interface changes. 9. Navigator
A major limitation of the existing CAS system is that access to legacy systems is through terminal emulation, such as screen scraping. Additionally, every message from a technician is processed individually. Thus, for each message received, the CAS servers would individually route the messages to the appropriate remote system and would also individually route each reply message returned to the technicians. Rather than screen scraping or other terminal emulation, the system preferably provides a more direct connection to certain legacy and other remote systems. For instance, the system preferably connects to LMOS and OPSCM through Navigator 171 that allows an efficient, effective access to LMOS and OPSCM without concern for changes to legacy Systems. The Navigator tool kit provides a messaging service delivering blocks of LMOS data to the TechNet server 28, 30. Currently, approximately 80% of the technician 12, customer premises work involves dispatching to correct troubles and to complete service orders. Thus, Navigator 171 access to LMOS increases technician's ability to efficiently perform job duties.
Figure 21 shows a representative example of TechNet Server components in each data center. Any equivalent component can be substituted for any of the above listed components listed in Figure 21.
It is envisioned that this invention will provide the described capabilities to technicians and the following enhancement features: immediate input and close-out of customer service requests; capture of customer signatures electronically; acceptance of credit card payments for installation of new services or repairs; automation of monthly mileage reports and motor vehicle repair requests; ordering materials and supplies; capabilities for technicians to train themselves on new services and procedures using a CD-ROM disk; access to e-mail, network construction data, and cable planning documents; and printing out a customer statement for services rendered, product information, job aids, customer instructions on the features and services installed and access an intranet. An advantage of this invention is that it provides technicians with remote access to remote systems such as legacy systems via a wireless communications network.
Another advantage of this invention is that where navigator is employed, the system is shielded from interface changes made to legacy systems. The forgoing description of the preferred embodiments of the invention has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching.
The embodiments were chosen and described in order to explain the principles of the invention and their practical application so as to enable others skilled in the art to utilize the invention and various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

What is claimed is: 1. A method for providing a mobile work force access to remote systems, such as legacy systems utilizing a communications network, comprising: receiving messages transported over the communications network, the messages requesting access to data stored in legacy systems; processing the messages utilizing a processor, the processor in communication with the legacy systems: and sending requested data from the legacy systems over the communications network.
2. The method of claim 1 , wherein the receiving comprises receiving the messages over a wireless network.
3. The method of claim 1 , wherein the receiving comprises receiving the messages over a wireline network.
4. The method of claim 1 , further comprising sending the messages from a portable personal computer (PC) to the communications network.
5. The method of claim 4, wherein the sending comprises displaying the messages and data from legacy systems on the PC.
6. The method of claim 5, wherein the processing comprises authenticating messages received from the PC.
7. The method of claim 5, wherein the processing comprises generating legacy systems transactions.
8. The method of claim 5, wherein the processing comprises receiving results from the legacy systems transactions.
9. The method of claim 5, wherein the processing comprises performing a synchronously updating, monitoring and providing current status of applications processes.
10. The method of claim 5, wherein the processing comprises segmenting the messages into data addresses required to fulfill the request and retrieving the requested legacy systems data and placing the data in a send queue for transport.
11. The method of claim 5, wherein the processing comprises providing administrative services to the local access providers and generating user reports.
12. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Computer System for Main Frame Operations (COSMOS).
13. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Loop Maintenance Operations System (LMOS).
14. The method of claim 13, further comprising directly accessing LMOS utilizing a navigator.
15. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Loop Facility Assignment Control System (LFACS).
16. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Work Activity Statistical Sampling Plan (WASSP).
17. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Mechanized Loop Testing (MLT).
18. The method of claim 5, wherein the receiving comprises requesting access to the legacy system Mechanized Time Reporting (MTR).
19. The method of claim 5, wherein the communications network further comprises receiving and forwarding messages utilizing at least one protocol server.
20. The method of claim 5, wherein the receiving comprises requesting access to the legacy system OutSide Plant Construction Management (OSPCM).
21. A processor for providing access to remote systems such as legacy systems over a communications network upon a user's request, comprising: a communications server for storing and forwarding a message; a transaction request broker for receiving, processing and authenticating the message; a screen scraper providing an interface between the transaction request broker and legacy systems, the screen scraper receiving the request from the transaction request broker and invoking the legacy system transaction and upon completion of the request sending the requested legacy system information to the transaction request broker; and a middleware processor for storing, parsing and forwarding the legacy system information to a portable personal computer (PC).
22. The processor of claim 21 , further comprising an administration server for providing remote access to the processor, the administration server including information on the users and systems for maintaining that information and producing reports.
23. The processor of claim 21 , further comprising a database server providing access to user profiles for authorizations performed by the transaction request broker and a report server for collecting data needed for reports.
24. The processor of claim 21 , further comprising a performance management process controller that becomes active at boot time of the processor and monitors all other processes of the processor, the performance management process controller logs process activities and restarts non-functioning processes.
25. The processor of claim 21 , further comprising a navigator adapted to interface with the legacy process, the navigator providing emulation of the legacy systems.
26. The processor of claim 21 , further comprising Ethernet cards and FDDI cards adapted to allow the processor to connect to the communications network and at least one data center.
27. The processor of claim 21 , further comprising a navigator system adapted to interface with the legacy systems Loop Maintenance Operations System (LMOS).
28. A method of providing a mobile work force access to legacy systems, the mobile work force utilize portable personal computers (PCs) adapted to interface with a communications network, comprising: receiving a request for data from the legacy system by a processor in communications with the portable PC; authenticating the request by the processor; servicing the request by the processor; generating the legacy system transaction by the processor; receiving results from the legacy system by the processor; sending the results to the portable PC by transmitting the results over the communications network.
29. The method of claim 28, wherein the authenticating further comprises: getting the request from a receive queue and processing the message; parsing the message; authenticating the user and PC combination; verifying the user's login status; determining the legacy system to be initiated for the transaction; making requests through predefined contracts to a hands off assignment logic or directly to the legacy systems; and logging all requests.
30. The method of claim 29, further comprising providing a screen scraping interface between the transaction request broker and the legacy systems.
31. The method of claim 30, wherein the screen scraping interface is performed utilizing hands off assignment logic.
32. The method of claim 31 , further comprising completing the request comprising: providing information by the hands off assignment logic to the transaction request broker upon completion of the request; placing the information by the transaction request broker into a send queue of the processor along with sender and receiver information; picking up message by a communications processor and placing the message onto an input/output socket: picking up the message by middleware having a block on that socket and placing the message in the sender's queue; determining a destination address of the sender and sending the message back to the sender's PC using the communications network; and receiving the message displaying the message on the sender's PC.
33. The method of claim 29, further comprising providing remote access to the processor by an administration server for maintaining user and system information and for producing reports.
34. The method of claim 29, further comprising providing access to user profiles by a database server for authorizations performed by the transaction request broker.
35. The method of claim 34, further comprising collecting data needed for reports by a report server.
36. The method of claim 28, further comprising monitoring all processes of the processor by a performance management process controller, the performance management process controller becoming active at boot time of the processor, logs process activities and restarts non- functioning processes.
37. A computer-readable medium for providing a mobile work force access to legacy systems, the mobile work force utilize portable personal computers (PCs) adapted to interface with a communications network, comprising: receiving a request for data from the legacy system by a processor in communications with the portable PC; authenticating the request by the processor; servicing the request by the processor; generating the legacy system transaction by the processor; receiving results from the legacy system by the processor; sending the results to the portable PC by transmitting the results over the communications network.
38. A method for utilizing a portable personal computer (PC) to remotely access legacy systems, the portable PC in communication with a communications network, comprising: recognizing a user request for legacy system data by the portable PC and formatting and sending that request to a server for processing, the server in communication with the legacy systems; receiving the legacy systems data by the portable PC; parsing the legacy systems data by the portable PC; and displaying the legacy systems data by the portable PC to the user.
39. The method of claim 38, further comprising logging the legacy system data into a client database.
40. The method of claim 38, further comprising managing the user to portable PC interface by a graphical user interface (GUI) layer wherein the managing includes capturing the user's actions, generating events, presenting data to the user and assisting in management of dialog flow.
41. The method of claim 40, further comprising: collecting information from the user; editing the information according to display options; coordinating activity across fields in a display window of the portable PC; managing the filed interdependencies; and invoking application logic based on a state of the fields and the user's actions.
42. The method of claim 41 , further comprising parsing the data by the GUI layer.
43. The method of claim 42, further comprising: sending the parsed data to a communications layer to be sent to the server; parsing information received from the server; displaying the information on the portable PC: and providing an audio notification to the user.
44. The method of claim 43, further comprising providing a VT100 session to the user.
45. The method of claim 38, further comprising communicating between the portable PC and the server by a middleware software, the middleware software providing synchronous and asynchronous modes of transmission, connection establishment and management, frame recovery, message compression, decompression and segmentation, re-transmission in an event of a communications network failure and data encryption.
46. The method of claim 45, further comprising shielding the application logic layer from any changes to the middleware software.
47. The method of claim 38, further comprising storing the user and transaction data by a client database which is remotely assessable.
48. The method of claim 47, further comprising preparing reports utilizing user and transaction data stored in the client database.
49. A computer-readable medium for storing software for use in performing a method of communication with a portable personal computer (PC) to remotely access legacy systems, the portable PC in communication with a communications network, the method comprising: recognizing a user request for legacy system data by the portable PC and formatting and sending that request to a server for processing, the server in communication with the legacy systems; receiving the legacy systems data by the portable PC; parsing the legacy systems data by the portable PC; and displaying the legacy systems data by the portable PC to the user.
50. A method of providing connectivity between a processor and mobile users utilizing both a wireless and a wireline communications network, comprising: arranging at least two separate arrays of individual protocol servers located in different data centers: balancing a traffic load between the protocol servers by one protocol server handling less traffic that the other protocol server and by supporting a greater number of individual connections into the wireline and wireless communications networks; and distributing evenly the traffic load between the protocol servers as the mobile users connect to the wireless and wireline communications networks.
51. The method of claim 50, wherein the balancing for a wireline communications network further comprises configuring one protocol server as a primary server address in a mobile configuration as specified in the mobile users personal computer profile and specifying at least one alternative protocol server IP address.
52. The method of claim 50, wherein the balancing for a wireless communications network further comprises requesting a connection to the array of individual protocol servers by the mobile users interfacing with a personal computer and assigning the connection to a specific individual protocol server by the wireless communications network.
53. A protocol server for providing connectivity between a wireless and wireline communications network and a processor adapted to interface with legacy systems to at least 15,000 mobile users, comprising: at least two arrays of individual protocol servers; and a middleware system implemented on the protocol server comprising: a message queue for storing outgoing messages until the individual protocol server responsible for sending the message retrieves the message; an RFexpress server for transmitting data from the message queue to both the wireless and wireline communications network; a remote messaging API server residing on the protocol server for providing communications between the processor and for transmitting messages between a remote messaging API client and the message queue; and a remote messaging API client residing on the processor responsible for communicating with the remote messaging API server.
54. A method of providing emulation of legacy systems, comprising: accessing legacy systems by utilizing a transaction request broker of a processor to request data; emulating the legacy systems utilizing a navigator adapted to interface with the legacy systems and the processor; obtaining the requested data by the processor; and sending the requested data to a user utilizing a communications network by the processor.
55. The method of claim 54, wherein the emulating the legacy systems utilizing a navigator adapted to interface with the legacy systems and processor is performed on an OutSide Plant Construction Management legacy system.
56. The method of claim 54, wherein the emulating the legacy systems utilizing a navigator adapted to interface with the legacy systems and processor is performed on the legacy system Loop Maintenance Operations System (LMOS) front end.
57. A method of providing access to legacy systems, comprising: accessing legacy systems by utilizing a transaction request broker of a processor to request data; emulating the legacy systems utilizing a hands off assignment logic terminal emulator adapted to interface with legacy systems and the processor; and obtaining the requested data by the processor.
58. The method of claim 57 further comprising: sending the requested data to a user utilizing a communications network by the processor.
PCT/US1999/014626 1998-07-01 1999-06-28 Systems and methods for utilizing a communications network for providing mobile users access to legacy systems WO2000002365A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU50856/99A AU5085699A (en) 1998-07-01 1999-06-28 Systems and methods for utilizing a communications network for providing mobile users access to legacy systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US9137398P 1998-07-01 1998-07-01
US60/091,373 1998-07-01

Publications (1)

Publication Number Publication Date
WO2000002365A1 true WO2000002365A1 (en) 2000-01-13

Family

ID=22227428

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/014626 WO2000002365A1 (en) 1998-07-01 1999-06-28 Systems and methods for utilizing a communications network for providing mobile users access to legacy systems

Country Status (2)

Country Link
AU (1) AU5085699A (en)
WO (1) WO2000002365A1 (en)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002079986A1 (en) * 2001-03-29 2002-10-10 British Telecommunications Public Limited Company Legacy system interface
US6754582B1 (en) 2001-10-25 2004-06-22 Bellsouth Intellectual Property Corp. Methods and systems for routing travel between origin and destination service locations using global satellite positioning
US6772064B1 (en) 2001-10-25 2004-08-03 Bellsouth Intellectual Property Corporation Methods and systems for determining a telecommunications service location using global satellite positioning
US6771744B1 (en) 2002-03-21 2004-08-03 Bellsouth Intellectual Property Corporation Methods and systems for data collection and processing in association with service performed in a telecommunications system
US7224787B1 (en) 2002-09-18 2007-05-29 Bellsouth Intelllectual Property Corporation Methods and systems for performing special service maintenance and installation operations in a telecommunications system
US7308482B2 (en) 2002-02-12 2007-12-11 At&T Bls Intellectual Property, Inc. Methods and systems for communicating with service technicians in a telecommunications system
US8166311B1 (en) 2002-06-20 2012-04-24 At&T Intellectual Property I, Lp Methods and systems for promoting authentication of technical service communications in a telecommunications system
US8843515B2 (en) 2012-03-07 2014-09-23 Snap Trends, Inc. Methods and systems of aggregating information of social networks based on geographical locations via a network
US8887177B2 (en) 2008-03-14 2014-11-11 William J. Johnson System and method for automated content distribution objects
US8886226B2 (en) 2008-03-14 2014-11-11 William J. Johnson System and method for timely whereabouts determination by a mobile data processing system
US8897741B2 (en) 2009-11-13 2014-11-25 William J. Johnson System and method for mobile device usability by locational conditions
US8942733B2 (en) 2008-03-14 2015-01-27 William J. Johnson System and method for location based exchanges of data facilitating distributed location applications
US8942693B2 (en) 2008-03-14 2015-01-27 William J. Johnson System and method for targeting data processing system(s) with data
US9477991B2 (en) 2013-08-27 2016-10-25 Snap Trends, Inc. Methods and systems of aggregating information of geographic context regions of social networks based on geographical locations via a network
US9894489B2 (en) 2013-09-30 2018-02-13 William J. Johnson System and method for situational proximity observation alerting privileged recipients
US10477994B2 (en) 2008-03-14 2019-11-19 William J. Johnson System and method for location based exchanges of data facilitiating distributed locational applications

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0712227A2 (en) * 1994-11-14 1996-05-15 Harris Corporation Trouble-shooting system for telephone system
US5687212A (en) * 1995-07-25 1997-11-11 Bell Atlantic Network Services, Inc. System for reactively maintaining telephone network facilities in a public switched telephone network
US5896440A (en) * 1994-05-26 1999-04-20 Gte Service Corporation System and method for providing a unified communications link between divergent communication networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5896440A (en) * 1994-05-26 1999-04-20 Gte Service Corporation System and method for providing a unified communications link between divergent communication networks
EP0712227A2 (en) * 1994-11-14 1996-05-15 Harris Corporation Trouble-shooting system for telephone system
US5687212A (en) * 1995-07-25 1997-11-11 Bell Atlantic Network Services, Inc. System for reactively maintaining telephone network facilities in a public switched telephone network

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002079986A1 (en) * 2001-03-29 2002-10-10 British Telecommunications Public Limited Company Legacy system interface
US7647172B2 (en) 2001-10-25 2010-01-12 At&T Intellectual Property I, L.P. Methods and systems for determining a telecommunications service location using global satellite positioning
US6772064B1 (en) 2001-10-25 2004-08-03 Bellsouth Intellectual Property Corporation Methods and systems for determining a telecommunications service location using global satellite positioning
US7188027B2 (en) 2001-10-25 2007-03-06 Bellsouth Intellectual Property Corporation Methods and systems for determining a telecommunications service location using global satellite positioning
US7292939B2 (en) 2001-10-25 2007-11-06 At&T Bls Intellectual Property, Inc. Methods and systems for determining a telecommunications service location using global satellite positioning method
US6754582B1 (en) 2001-10-25 2004-06-22 Bellsouth Intellectual Property Corp. Methods and systems for routing travel between origin and destination service locations using global satellite positioning
US8135540B2 (en) 2001-10-25 2012-03-13 At&T Intellectual Property I, Lp Methods and systems for determining a telecommunications service location using global satellite positioning
US7308482B2 (en) 2002-02-12 2007-12-11 At&T Bls Intellectual Property, Inc. Methods and systems for communicating with service technicians in a telecommunications system
US8150940B2 (en) 2002-02-12 2012-04-03 At&T Intellectual Property I, Lp Methods and systems for communicating with service technicians in a telecommunications system
US6771744B1 (en) 2002-03-21 2004-08-03 Bellsouth Intellectual Property Corporation Methods and systems for data collection and processing in association with service performed in a telecommunications system
US8166311B1 (en) 2002-06-20 2012-04-24 At&T Intellectual Property I, Lp Methods and systems for promoting authentication of technical service communications in a telecommunications system
US7224787B1 (en) 2002-09-18 2007-05-29 Bellsouth Intelllectual Property Corporation Methods and systems for performing special service maintenance and installation operations in a telecommunications system
US7596214B2 (en) 2002-09-18 2009-09-29 At&T Intellectual Property I, L.P. Methods and systems for performing special service maintenance and installation operations in a telecommunications system
US8942693B2 (en) 2008-03-14 2015-01-27 William J. Johnson System and method for targeting data processing system(s) with data
US9445238B2 (en) 2008-03-14 2016-09-13 William J. Johnson System and method for confirming data processing system target(s)
US8886226B2 (en) 2008-03-14 2014-11-11 William J. Johnson System and method for timely whereabouts determination by a mobile data processing system
US10477994B2 (en) 2008-03-14 2019-11-19 William J. Johnson System and method for location based exchanges of data facilitiating distributed locational applications
US10111034B2 (en) 2008-03-14 2018-10-23 Billjco Llc System and method for sound wave triggered content
US8923806B2 (en) 2008-03-14 2014-12-30 William J. Johnson System and method for presenting application data by data processing system(s) in a vicinity
US8942733B2 (en) 2008-03-14 2015-01-27 William J. Johnson System and method for location based exchanges of data facilitating distributed location applications
US9584993B2 (en) 2008-03-14 2017-02-28 William J. Johnson System and method for vector processing on behalf of image aperture aim
US8942732B2 (en) 2008-03-14 2015-01-27 William J. Johnson Location based exchange operating system
US9014658B2 (en) 2008-03-14 2015-04-21 William J. Johnson System and method for application context location based configuration suggestions
US9055406B2 (en) 2008-03-14 2015-06-09 William J. Johnson Server-less synchronized processing across a plurality of interoperating data processing systems
US9078095B2 (en) 2008-03-14 2015-07-07 William J. Johnson System and method for location based inventory management
US9088869B2 (en) 2008-03-14 2015-07-21 William J. Johnson System and method for application search results by locational conditions
US9088868B2 (en) 2008-03-14 2015-07-21 William J. Johnson Location based exchange permissions
US9100792B2 (en) 2008-03-14 2015-08-04 William J. Johnson System and method for service-free location based applications
US9113295B2 (en) 2008-03-14 2015-08-18 William J. Johnson System and method for location based exchange vicinity interest specification
US9204275B2 (en) 2008-03-14 2015-12-01 William J. Johnson System and method for targeting data processing system(s) with data
US9253597B2 (en) 2008-03-14 2016-02-02 William J. Johnson System and method for determining mobile users of interest
US9392408B2 (en) 2008-03-14 2016-07-12 William J. Johnson System and method for location based exchanges of data facilitating distributed locational applications
US8887177B2 (en) 2008-03-14 2014-11-11 William J. Johnson System and method for automated content distribution objects
US9456303B2 (en) 2008-03-14 2016-09-27 William J. Johnson System and method for service access via hopped wireless mobile device(s)
US8897742B2 (en) 2009-11-13 2014-11-25 William J. Johnson System and method for sudden proximal user interface
US8897741B2 (en) 2009-11-13 2014-11-25 William J. Johnson System and method for mobile device usability by locational conditions
US8843515B2 (en) 2012-03-07 2014-09-23 Snap Trends, Inc. Methods and systems of aggregating information of social networks based on geographical locations via a network
US9626446B2 (en) 2012-03-07 2017-04-18 Snap Trends, Inc. Methods and systems of advertising based on aggregated information of social networks within geographical locations via a network
US9477991B2 (en) 2013-08-27 2016-10-25 Snap Trends, Inc. Methods and systems of aggregating information of geographic context regions of social networks based on geographical locations via a network
US9894489B2 (en) 2013-09-30 2018-02-13 William J. Johnson System and method for situational proximity observation alerting privileged recipients
US10194293B2 (en) 2013-09-30 2019-01-29 William J. Johnson System and method for vital signs alerting privileged recipients

Also Published As

Publication number Publication date
AU5085699A (en) 2000-01-24

Similar Documents

Publication Publication Date Title
US6738815B1 (en) Systems and methods for utilizing a communications network for providing mobile users access to legacy systems
US6515968B1 (en) Integrated interface for real time web based viewing of telecommunications network call traffic
WO2000002365A1 (en) Systems and methods for utilizing a communications network for providing mobile users access to legacy systems
US6868444B1 (en) Server configuration management and tracking
US6961778B2 (en) Management interface between a core telecommunication system and a local service provider
US6625651B1 (en) On-line transaction control during activation of local telecommunication service
US6266695B1 (en) Telecommunications switch management system
US5961594A (en) Remote node maintenance and management method and system in communication networks using multiprotocol agents
US5825769A (en) System and method therefor of viewing in real time call traffic of a telecommunications network
US20020073188A1 (en) Method and apparatus for partitioning system management information for a server farm among a plurality of leaseholds
US7672262B2 (en) System, method, and apparatus for command and control of remote instrumentation
US7269641B2 (en) Remote reconfiguration system
US6813278B1 (en) Process for submitting and handling a service request in a local service management system
US20020004390A1 (en) Method and system for managing telecommunications services and network interconnections
WO1999016198A1 (en) Integrated interface for real time web based viewing of telecommunications network call traffic
US6247052B1 (en) Graphic user interface system for a telecommunications switch management system
US6732167B1 (en) Service request processing in a local service activation management environment
US20020032769A1 (en) Network management method and system
US8566437B2 (en) Systems and methods for improved multisite management of converged communication systems and computer systems
US6836803B1 (en) Operations architecture to implement a local service activation management system
US6771758B1 (en) Reconciling database information among service providers
US20030233434A1 (en) Multi-tiered remote enterprise management system and method
US7554938B1 (en) System and method for providing an instant messaging function using a personal computer equipped with a wireless digital packet-switched modem
US7401144B1 (en) Technician intranet access via systems interface to legacy systems
CN102130944B (en) Method for monitoring and managing ATM and self-service system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase