| Preamble for synchronization -> Monitor Keywords |
|
|
 
Preamble for synchronizationRelated Patent Categories: Pulse Or Digital Communications, Transceivers, Modems (data Sets)Preamble for synchronization description/claimsThe Patent Description & Claims data below is from USPTO Patent Application 20070223568, Preamble for synchronization. Brief Patent Description - Full Patent Description - Patent Application Claims
FIELD OF THE DISCLOSURE [0001] The present disclosure relates to performance of data communication lines in communication networks. BACKGROUND [0002] Trouble ticket and work flow administration systems for telecommunication services, such as DSL service (DSL, ADSL, VDSL, etc.) use mainframe computer-based file systems to compile data for management of trouble tickets relating to data communication lines (such as Digital Subscriber Lines (DSL Lines or DSL Links)) that connect network elements, such as switches at wire centers or central offices, to customer premises equipment, such as DSL modems. Each new trouble with the DSL service for a line typically results in the creation of a trouble ticket that has a unique identification number. A single file is typically associated with each trouble ticket. In a typical network, there may be several mainframe system locations of an Internet Service Provider (ISP) that handle trouble tickets for the network. Each central office typically has several switches, each switch connecting to several hundred customer DSL Jines via a dedicated port for each such line. In the mainframe-based systems, each client or user, such as a service personnel of an ISP, is provided a graphical user interface (GUI) that the user can use to access a mainframe or backend system. A GUI typically uses a prompt response format. Upon receiving a user command for a particular line, the backend system retrieves the file relating to the trouble ticket for that line and sends it to the user. It typically takes several screen navigation and key strokes to read from the file. Also, field technicians typically do not have GUI interface. Technicians typically use handheld test devices to test the line at the customer end to gather performance data and convey the performance data and other information to the GUI users over telephone. The field test results are then sent to the appropriate mainframes by the GUI user, which can require multiple manual entries. [0003] Additionally, field technicians typically do not have the ability to remotely cause network elements, such as DSLAMs and metallic line testers, to take new or real-time performance data for a line while at a customer premises or another remote location. Field personnel also generally do not have access to the real-time performance data or the historical data for evaluating and troubleshooting the line. Thus, there is a need for an improved system for accessing new and historical line performance data and for communicating the field test results to the backend systems, such as the mainframes. BRIEF DESCRIPTION OF THE DRAWINGS [0004] For detailed understanding of the present disclosure, references should be made to the following detailed description of the embodiments, taken in conjunction with the accompanying drawings, in which like elements have been given like numerals, and wherein: [0005] FIG. 1 is a block diagram of an embodiment of a web-based DSL line management system for accessing DSL line performance data and for providing field test data to a backend system; [0006] FIG. 2 is an example of a screenshot that illustrates a web portal provided to a user device and line performance data that may be displayed on the user device; [0007] FIG. 3 is an example of a screenshot of a line analysis for display; [0008] FIG. 4 is an example of a screenshot of line code violation data for display; [0009] FIG. 5 is an example of a diagram of an input screen for a user to send field performance data and other information to the web servers in the system of FIG. 1; [0010] FIG. 6 is a flowchart that illustrates a particular embodiment of a method of accessing DSL data and for sending field test results to a backend system; and [0011] FIG. 7 is a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, when executed, may cause the machine to perform any one or more of the methodologies discussed herein. DETAILED DESCRIPTION OF THE DRAWINGS [0012] FIG. 1 shows a system 100 for managing performance of digital subscriber lines of a communications network, including initiating real-time collection of digital subscriber line performance data by a remote device via a wireless network or the Internet, accessing such data in the field and providing field test data and other information for the lines to a backend system that manages trouble ticket information for the lines. The system 100 has an extranet user interface via a wireless network and/or the Internet 170. The system 100 includes a first server, such as a resource center web server 104 having an input 190 with respect to an extranet user device 106 (also referred to as the user), such as a portable computer, PDA, etc. The system also includes a second web server 102, that among other things can map a digital subscriber line identifier or telephone number to a port associated with providing a service to the line and a plurality of regional servers 120, 122, 124, 126. The identifier may also be an Internet Protocol address or a CPE identifier, such as a DSL modem number. The system 100 further includes a plurality of digital subscriber line access multiplexer (DSLAM) management units 140, 142, 144, 146. Each of the DSLAM management units is coupled to a plurality of DSLAM equipment units, such as DSLAM equipment 150-164, as illustrated. In a particular embodiment, the DSLAM equipment supports a plurality of digital subscriber line broadband communication links or lines, such as line 189, to customer premises equipment (CPE) 191. The DSL links supported by the DSLAMs typically cover a diverse geographical areas, such as across many states. For example, the particular illustrated system may include several thousand DSLAMs covering several million ADSL lines across several different states. [0013] The line identifier or telephone number (TN) to port mapping server 102 is coupled to the resource center server 104 via an intermediate firewall 180. The resource center web server 104 is coupled to the extranet ISP user system 106 via a firewall 193. The resource center web server 104 provides performance analysis data that may be displayed on the extranet ISP user device 106 via system 170. The port mapping server 102 includes logic to provide an extensible markup language (XML) interface 172 to external application clients 110. The server 102 also provides a telephone number interface 174 and access to performance analysis to the intranet users 108. The port mapping server 102 includes web servers 101 and has access to a primary database 103 and secondary database 105 to perform the telephone number to port mapping and other performance analysis functions. An example database is implemented as an SQL type database. Server 102 is coupled to the regional servers 120 to 126 via firewall 184. Each of the regional servers 120-126 includes skeleton code and data collection engine. Each regional server is coupled to a respective DSLAM management module via a communication line, such as TL1 line, labeled 178. [0014] During system operation, an ISP personnel logs on via the network 170, for example using GPRS (General Packet Radio Service) wireless network and VPN (Virtual Private Network) to access the server 104 across firewall 193. The web server 104 then provides a web portal to the user device 106. An example of the web portal is shown in FIG. 2. The ISP personnel inputs an identifier, such as a telephone number 202 (FIG. 2) that is received at the resource center web server 104 from the extranet ISP user device 106. The telephone number is then passed to the server 102 across firewall 180 and is received at the web server 101, which may include a stub server. The web server 102 performs a database query such as an SQL query to the database units which perform telephone number to port mapping. The DSL multiplexer address port corresponding to the particular telephone number received is then provided by the database to logic within a stub portion of the server 102. [0015] The port address is then provided across firewall 184 to the designated regional server that supports a particular DSLAM having the selected port address. The port address is provided to the appropriate regional server and the regional server then communicates the port address across the communication link to the respective DSLAM management unit. For example, where the selected regional server that supports the DSLAM matching a DSL line having the input telephone number is regional server 120, the port address is then provided to the DSLAM management unit 140 which then performs real-time data collection of the performance of the associated DSL line, such as a DSL line 189, supported by DSLAM 150. In one aspect, the real-time performance may be done by DSLAM at the network end according to programmed instructions and/or by other test devices, such as metallic loop testers connected to the network end. After the performance tests are performed and real time data for the DSL line with the selected port address is collected at the DSLAM unit, the collected data is received at the collection engine within the regional server 120 and is passed back to the server 102 for reporting to the appropriate user. In one aspect, the raw data collected from regional server 120 is processed by performance analysis tools associated with the server 102. The resulting processed and analyzed data is reported to application clients 110, intranet users 108 and/or extranet ISP users 106. [0016] Still referring to FIG. 1, the server 102 is shown coupled to a backend system 112 that includes a plurality of mainframe systems 130 and 132, each respectively having an associated database 131 and 133. The mainframe systems may be located in diverse geographical regions of the ISP and manage trouble ticket data for the DSL lines of the network 100. The web server 102 communicates or interfaces with each of the mainframe systems in the backend system 112 via an appropriate emulator, such as "3270" emulator. The "3270" emulator allows connection of the web server 102 with the mainframes systems via TCP/IP. It can also support web services via XML. When a trouble is reported on a particular DSL line, a trouble ticket is generated corresponding to the identifier or telephone number associated with the affected line. A single file typically is associated with the trouble ticket. A particular mainframe system in the backend system 112 maintains the trouble ticket data for the line. In general each mainframe system maintains trouble ticket data for a large set of DSL lines, generally for selected geographical regions. Each DSL line corresponds to a particular node of a large number of nodes in the backend system for properly routing data for the line to the appropriate mainframe system. [0017] Still referring to FIG. 1, the web server 102 includes an authentication component that enables the server 102 to authenticate itself to all of the nodes in the backend system, even when different nodes may require a different way for identification. Also, the web server 102 includes a communication component that enables it to remain in communication with all of the geographically dispersed nodes comprising the backend system of records. The web server 102 also may employ a method of injecting timely traffic on the communication channels on all nodes to allow these channels to persist indefinitely, whereas in the course of normal usage by ISP operators, such communication channels could be discarded by the nodes after a certain time period. The web server 102 also may include a time-sharing mechanism that allows the system to aggregate a large number of updates that may be concurrently performed by various field personnel. [0018] The user 106 often performs one or more tests at the customer end on the DSL line and the CPE, such as a DSL modem. The user also often collects performance data that is stored in the CPE. Additionally, the user may draw certain conclusions relating to the performance and condition of the DSL line and the CPE. The server 102 or 104 provides to the user a screenshot where the user can enter such data and information and send back such data to the server 102 via the network 170. An example of a screenshot that may be provided to the user to enter and report back the field data is shown and described in reference to FIG. 5. [0019] When the user sends the line performance data from the field via the network 170, the server 102 converts this web-based collected data to a mainframe format and sends the converted data to the node in the backend system that is associated with the DSL line. The sent data may include the field performance data, real-time performance data and historical data for the line. The backend system then sends the received data to the appropriate mainframe system that stores the data in the trouble ticket file of the line or in another suitable file. [0020] In one aspect, after the web-based system has captured the DSL performance data or metrics and a decision is made to update the backend system of record for work assignment and control administration, the DSL performance metrics are automatically transferred to perform the update. The web system 103 also is capable of merging any additional information provided by the field technician into the record to be updated. Also, the identifier information for the DSL line being tested is transferred over to the record that is to be updated. Based on the identifier information for the DSL line, system 102 automatically determines the node within the backend system of record to be updated. The system 102 then simulates the keystrokes and other entries normally performed by an operator to locate the record to be updated within the backend system, and verifies the responses from the backend system to ascertain that the correct record was retrieved. The system then simulates the keystrokes and entries to enter the DSL performance metrics and the field technician's additional information to the appropriate node within the backend system. The system then inserts the appropriate code required by the backend system of record to propagate the update to various dependent subsystems. Continue reading about Preamble for synchronization... Full patent description for Preamble for synchronization Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Preamble for synchronization patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Preamble for synchronization or other areas of interest. ### Previous Patent Application: Preamble for synchronization Next Patent Application: Digital signal analysis program and waveform display apparatus Industry Class: Pulse or digital communications ### FreshPatents.com Support Thank you for viewing the Preamble for synchronization patent info. IP-related news and info Results in 0.83026 seconds Other interesting Feshpatents.com categories: Novartis , Pfizer , Philips , Polaroid , Procter & Gamble , 174 |
 * Protect your Inventions * US Patent Office filing 
PATENT INFO |
|
