WO1997008616A1 - Systeme et methode d'analyse et d'elaboration de signaux de donnees - Google Patents

Systeme et methode d'analyse et d'elaboration de signaux de donnees Download PDF

Info

Publication number
WO1997008616A1
WO1997008616A1 PCT/US1996/009821 US9609821W WO9708616A1 WO 1997008616 A1 WO1997008616 A1 WO 1997008616A1 US 9609821 W US9609821 W US 9609821W WO 9708616 A1 WO9708616 A1 WO 9708616A1
Authority
WO
WIPO (PCT)
Prior art keywords
data stream
individual pieces
parsing
data
error
Prior art date
Application number
PCT/US1996/009821
Other languages
English (en)
Inventor
Rohini V. Marathe
Subramanya Shastry
Original Assignee
Bell Communications Research, 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 Bell Communications Research, Inc. filed Critical Bell Communications Research, Inc.
Publication of WO1997008616A1 publication Critical patent/WO1997008616A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing

Definitions

  • the present invention relates generally to techniques for parsing data signals, and more specifically to parsing data signals transmitted between modules in a telecommunications network.
  • a telecommunications network passes information between modules within the network via data signals.
  • the signals which are simply streams of data bits, require some method of organization so that the network modules can understand and communicate the data.
  • Signals passing between modules of a telecommunications system are formatted according to data formats.
  • One data format the Binary Encoding Rules ("BER") format, organizes data into bytes of eight bits and specifies the order of the various bytes.
  • BER is a machine-readable form of the human- readable format of Abstract Syntax Notation ("ASN.l").
  • source modules use builders to format groups of data bytes so that they may be transmitted as decipherable signals.
  • Destination modules use parsers, coordinated in format with the builders, to extract the data bytes from the transmitted signals.
  • the messages are specified using ASN.l in interface documents between two modules. Computer programs are then developed to translate the messages that adhere to the ASN.l specification into BER format for transmission between modules in the network.
  • the ASN.l specification language and the BER format description can be found in "THE OPEN BOOK: A Practical Perspective on OSI", by Marshall T. Rose (Prentice Hall 1990) .
  • Different .types of messages may have different types of ASN.l specifications, resulting in different BER streams. Examples of , ASN.l message specifications are AIN-0 protocol specification and AIN-0.1 protocol specification. Each specification requires that its own parsing routine and building routine be compiled.
  • AIN-0 and AIN-0.1 for example, the builder must create and compile separate parsing routines and building routines.
  • the user of the network must create and compile new parsing and building routines for each specification and integrate these new routines into each specification. This makes it very complicated to add new messages or protocol specifications to the network.
  • Fig. IA is a block diagram showing an exemplary background parser 110 and Fig. IB is a block diagram showing an exemplary background builder 115.
  • the parser 110 is connected to an application module 120 and is used to parse an input signal 105.
  • the parser 110 includes at least one parsing routine 130 and at least one parsing memory 140.
  • the parser 110 accepts the input data from the input-data signal byte-by-byte and, based on the order of the incoming bytes and the instructions contained in the parsing routine 130, places the bytes into portions of the parsing memory 140.
  • the application module 120 then extracts the data from the portions of the parsing memory 140. As shown in Fig.
  • the parser 110 contains one parse route for each supported message.
  • Fig. 2A is a flowchart of the operation of the parser 110 of Fig. IA.
  • the parser 110 begins by receiving the current byte of data from the input signal (step 200) .
  • the parsing routine 130 detects whether there is any error in the received byte of data (step 205) and, if it detects an error, exits to an error handling routine for processing the detected error (step 210) . If the parsing routine 130 detects no error in the received byte of data, it places the received byte of data into the portion of the parsing memory 140 corresponding to that data byte (step 215) .
  • the parsing routine 130 is programmed with the appropriate memory locations corresponding to each of the data bytes contained in the input signal .
  • the parsing routine 130 determines whether the last byte of the input signal has been received (step 220) . If the last byte has not been received, the parsing routine 130 moves on to the next byte in the input signal (step 225) and returns to step 200. If the last byte of the input signal has been received, the parsing routine 130 reports successful parsing to the application module 120 (step 230) and ends processing.
  • the builder 115 is connected to the application module 120 and is used to construct an output signal for transmission.
  • the builder 115 includes a building routine 135 and a building memory 145.
  • the application module 120 places bytes of data to be transmitted within the network into portions of the building memory 145.
  • the builder 115 then extracts the bytes of data from the building memory 145 and, based on the memory locations of the byte of data and instructions contained in the building routine 135, arranges the bytes into an output signal and transmits the output signal.
  • builder 115 contains one build routine for each supported message.
  • Fig. 2B is a flowchart of the operation of the builder 115 of Fig. IB. As shown in Fig. 2B, the builder 115 begins by extracting from the building memory 145 the byte of data corresponding to the first byte of data for the output signal
  • the building routine 135 determines whether there is any error in the extracted byte of data (step 255) and, if it detects an error, exits to an error handling routine for processing the detected error (step 260) . If it detects no error in the extracted byte of data, the building routine 135 stores the extracted byte of data as the first byte of the transmitted signal
  • the building routine is programmed with the appropriate memory location for each of the data bytes required to construct the data signal .
  • the building routine 135 determines whether the last byte required for the output signal has been extracted (step 270) . If the last byte has not been extracted, the building routine 135 moves on to the next byte for the output signal (step 275) and returns to step 250. If the last byte of the incoming signal has been extracted, the building routine 135 transmits the output signal (step 280) and ends processing.
  • the application module 120 is blind to the data format being used. The only information available to the application module is where in the parser memory 140 each byte of the incoming signal will be placed and where in the building memory 145 each byte for the outgoing signal will be placed.
  • the parsing routine 130 contains the information necessary to properly route the incoming data bytes into their proper locations in the parser memory 140.
  • the building routine 135 contains the information necessary to properly extract the outgoing data bytes from the proper locations in the building memory 145 and arrange the bytes in the proper order according to the output signal's required format.
  • each parsing routine 130 and building routine 135 is specifically designed to decipher a given data format, a separate parsing routine 130 and building routine 135 are required for each new data format that may be used by the application module 120.
  • the parsing and building routines can be a set of computer programs using a programming language such as C. Each parsing routine implements the logic shown in Fig. 2A and each build routine implements the logic shown in Fig. 2B.
  • the parsing memory 140 may be a data structure, the elements of which are referenced by the parsing routine 130 and the application module 120.
  • the building memory 145 may be a data structure, the elements of which are referenced by the building routine 135 and the application module 120.
  • ASN.l compilers e.g., DSET compiler supported by DSET Corporation
  • DSET compilers DSET compiler supported by DSET Corporation
  • These compilers use the ASN.l specification as input and produces the parsing and building routines 140 and 145 and the data structure formats. If the ASN.l specification is changed, then it is necessary to regenerate the parsing and building routines 140 and 145 and to change the application module 120 to reference the newly changed data structures.
  • the parser 110 or builder 115 stops processing and enters an error handling routine immediately upon detecting an error, if an input signal or a builder memory 145 contains multiple errors, the parser 110 or builder 115 stops upon encountering the first error which is not the behavior expected of a network application.
  • the present invention is directed to a system and method for parsing or building a data signal that substantially obviates one or more of the problems due to limitations and disadvantages of the related art.
  • the present invention overcomes the limitations and disadvantages noted above through the use of definition files that contain information relating to one or more data formats and information on various types of error handling. This allows the use of generic parsing and building routines that obtain any data particular to a given data format from the definition files. This also allows the parsing and building routine to identify all of the errors associated with an input or output signal before any error handling routine is invoked.
  • the invention includes, an automatic parser for parsing a data stream, comprising: a memory containing a definition file; means for receiving the data stream; means for decomposing the received data stream into individual pieces of data based on parsing information in the definition file; and means for transmitting the individual pieces of data.
  • the invention includes, an automatic builder for creating an output data stream, comprising: a memory containing a definition file; means for receiving a plurality of individual pieces of data; and means for composing the output data stream out of the individual pieces of data based on composing information in the definition file.
  • the invention also includes a method for automatically parsing an input data stream, including the steps, executed by a processor, of: receiving the input data stream; decomposing the received input data stream into individual pieces of data based on decomposing information stored in a definition file residing in a memory; and transmitting the individual pieces of data.
  • the invention includes a method for automatically creating an output data stream, including the steps, executed by a processor, of: receiving a plurality of individual pieces of data; composing the output data stream out of the individual pieces of data based on composing information stored in a definition file residing in a memory; and transmitting the composed output data stream.
  • an automatic parser for parsing a received data stream and creating an output data stream, comprising: a memory containing an input definition file; a memory containing an output definition file; means for decomposing the received data stream into a plurality of individual pieces of input data based on information in the input definition file; means for transmitting the individual pieces of data; means for receiving a plurality of individual pieces of output data; and means for composing the output data stream out of the plurality of individual pieces of output data based on information in the output definition file.
  • Fig. IA is a block diagram showing a prior art parser
  • Fig. IB is a block diagram showing a prior art builder
  • Fig. 2A is a flowchart showing the steps performed by a parsing routine in parsing a data signal
  • Fig. 2B is a flowchart showing the steps performed by a building routine in composing a data signal
  • Fig. 3A is a block diagram showing a parser according to a preferred embodiment of the current invention.
  • Fig. 3B is a block diagram showing a builder according to a preferred embodiment of the current invention.
  • Fig. 4A is a flowchart showing the steps performed by a parsing routine in parsing a data signal according to a preferred embodiment of the current invention
  • Fig. 4B is a flowchart showing the steps performed by a building routine in composing a data signal according to a preferred embodiment of the current invention.
  • Figs. 3A and 3B are block diagrams showing a parser 310 and a builder 315, respectively, according to a preferred embodiment of the present invention.
  • the parser 310 is connected to an application module 320 and is used to parse an input signal.
  • the parser 310 includes a parsing routine 330, a parsing memory 340, and at least one parsing definition file 350.
  • the parsing routine 330 is a computer program, such as a C program, executed by a microprocessor (not shown) .
  • the parsing routine 330 may be written in any suitable programming language and may be executed by any suitable microprocessor.
  • the parsing memory 340 may comprise any suitable computer memory device, such as IC ROM or RAM, or disk memory.
  • the parsing definition file 350 is preferably a data file, so that it can be easily changed using a commercially available editor. An example of such a file is shown in Appendix Al . Preferably, this data file can be automatically generated from a corresponding ASN.l specification, shown in Appendix A2.
  • the parser 310 accepts the input data byte-by- byte from the input-data signal 305 and, based on the instructions contained in the parsing routine 330 and the parsing definition file 350, places the received bytes into portions of the parsing memory 340.
  • Fig. 4A is a flowchart of the operation of the parser 310 of Fig. 3A.
  • the parser 310 begins by detecting the format of the input signal (step 400) and receiving the current byte of data from the input signal (step 405) .
  • the format of the input signal is normally identified by the first few bytes of data in the input signal (usually referred to as the header in the input signal) .
  • the parsing routine 330 determines whether there is any error in the received byte of data (step 410) and, if it detects an error, stores information regarding the error according to information in the parsing definition file 350 (step 415) .
  • the parsing routine 330 If the parsing routine 330 detects no error in the received byte of data, it accesses the parsing definition file 350 to determine what address in the parsing memory 340 the received byte of data corresponds to (step 420) . Then, the parsing routine 330 writes the received data byte into the corresponding address of the parsing memory 340 (step 425) . After processing the received byte of data or storing error information, the parsing routine 330 determines whether the last byte of the input signal has been received (step 430) . If the last byte has not been received, the parsing routine 330 moves on to the next byte of the input signal (step 435) and returns to step 405.
  • the parsing routine 330 determines whether any errors have been detected during the entire processing of the signal (step 440) . If an error has been detected, the parsing routine 330 exits to an error handling routine to process the detected errors (step 443) . If no errors have been detected, the parsing routine 330 reports a successful parsing to the application module 120 (step 445) and ends processing.
  • Different levels of error checking can be performed by the parsing routine 330.
  • Some examples include explicit error checking, implicit error checking, protocol error checking, and existency checking.
  • explicit error checking a specific error routine is associated with a parameter in the input signal .
  • An example is shown in the definition in Appendix Al for the parameter ID.
  • the command RANGECHKd, 100) identifies the range of values for the parameter.
  • implicit error checking only certain values are allowed, depending upon the data type. For example, if the data parameter is identified as DIGITS, only valid binary coded digits (0, 1, . . ., 9 , * , #) are allowed in the input signal.
  • protocol error checking the input signal is checked for proper protocol standards. For example, every parameter must be encoded according to BER rules.
  • existency checking optional parameters may or may not exist in the input signal. These parameters are identified by the keyword "OPTIONAL" in the definition file.
  • the builder 315 is connected to the application module 120 and is used to construct an output signal 360 for transmission from the application module 120.
  • the builder 315 includes a building routine 335, a building memory 345, and at least one building definition file 355.
  • the building routine 335 is a computer program, such as a C program, executed by a microprocessor (not shown) .
  • the building routine 335 may be written in any suitable programming language, and may be executed by any suitable microprocessor.
  • the building memory 345 may comprise any suitable computer memory device, such as IC ROM or RAM, or disk memory.
  • the building definition file 355 is preferably also a data file similar to the parsing definition file 350.
  • the building definition file 355 may be the same as the file shown in Appendix Al .
  • the building routine 335 constructs the output signal 360 that adheres to the BER encoding for the ASN.l specification of the output signal shown in Appendix A2.
  • the application module 120 places data to be transmitted within the network into portions of the building memory 345, from which memory portions the builder 315 then extracts the data bytes. Based on building memory 345 locations, instructions contained in the building routine 135, and information in the building definition file 355, the building routine 335 then orders the data bytes into an output signal and transmits the output signal .
  • Fig. 4B is a flowchart of the operation of the building routine 335 of Fig. 3B.
  • the building routine 335 begins by determining the desired format of the output signal (step 450) .
  • the kind of format used for creating the output signal 360 is specified by the application module 320.
  • the building routine 335 accesses the building definition file 355 to determine the location in the builder memory 345 corresponding to the current byte in the output signal (step 455) and extracts the current byte from the proper location (step 455) .
  • the building routine 335 determines whether there is any error in the extracted byte of data (step 465) and, if it detects an error, stores error information for later processing (step 470) . If it detects no error in the extracted byte of data, the building routine 335 stores the extracted byte of data as the next byte of the transmitted signal (step 475) .
  • the building routine 335 determines whether the last byte required for the output signal has been extracted (step 480) . If the last byte has not been extracted, the building routine 335 moves to the next byte in the output signal (step 485) and returns to step 455. If the last byte of the incoming signal has been extracted, the building routine 335 determines whether any errors have been detected during the entire processing of the signal (step 490) . If errors have been detected, the building routine 335 exits to an error handling routine to process the detected errors (step 493) . If no errors have been detected, the building routine 335 transmits the output signal (step 495) and ends processing.
  • the parsing routine 330 and the building routine 335 do not contain any information specific to the handling of any particular data format, but rely on the definition files 350 and 355 to provide all such information. Because the definition files 350 and 355 can contain information related to multiple data formats, a separate parser 310 and builder 315 or a separate parsing routine 330 and building routine 335 are not required for each format that may be used. In addition, this allows for greater flexibility for the parser 110 and builder 115 since new formats can be added to their capabilities by simply editing the definition file.
  • the definition files 350 and 355 preferably contain information relating to the handling of errors, including basic information on how to process the errors prior to the execution of an error handling routine. This allows the parser 110 and builder 115 to process an entire input signal or an entire constructed output signal to detect all of the errors present in the signal before executing the error handling routine. This reduces the time necessary for processing any signal having more than one error by eliminating the need to process the signal once for every error present.
  • the present embodiment refers to input and output signals comprised of information broken up into bytes
  • other types of signals may also be processed.
  • the signal could be broken up into single bits of information, multiple-byte groups, or any other desired division of the signal data.

Abstract

Un analyseur automatique (310) reçoit un flux de données (305) et le décompose en éléments individuels de données sur la base des informations de décomposition d'informations mémorisées dans un fichier (350) de définitions puis transmet les éléments individuels de données à une mémoire (340) sur la base des données de décomposition. L'analyseur peut également détecter les erreurs dans un flux de données codées reçues, sur la base d'informations concernant les erreurs et peut traiter n'importe quelle erreur détectée. L'analyseur attend d'avoir détecté toutes les erreurs dans le flux de données reçues avant de commencer à en traiter une seule. En stockant plusieurs ensembles distincts d'informations d'analyse, correspondant chacun à un format différent, l'analyseur peut décomposer des messages de plusieurs formats en déterminant initialement le format du flux de données reçues et en utilisant le format approprié. Ce processus peut également être effectué en sens inverse par un développeur.
PCT/US1996/009821 1995-08-29 1996-06-11 Systeme et methode d'analyse et d'elaboration de signaux de donnees WO1997008616A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US52052695A 1995-08-29 1995-08-29
US08/520,526 1995-08-29

Publications (1)

Publication Number Publication Date
WO1997008616A1 true WO1997008616A1 (fr) 1997-03-06

Family

ID=24072986

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/009821 WO1997008616A1 (fr) 1995-08-29 1996-06-11 Systeme et methode d'analyse et d'elaboration de signaux de donnees

Country Status (2)

Country Link
TW (1) TW305091B (fr)
WO (1) WO1997008616A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998055921A1 (fr) * 1997-06-04 1998-12-10 Telefonaktiebolaget Lm Ericsson Systeme et procede relatifs a une manipulation generique de donnees
WO1999003036A1 (fr) * 1997-07-11 1999-01-21 Telefonaktiebolaget Lm Ericsson (Publ) Traduction d'appel de procedure a distance
GB2327515A (en) * 1997-06-10 1999-01-27 Ibm Message handling
WO2004001518A2 (fr) * 2002-06-24 2003-12-31 Koninklijke Philips Electronics N.V. Dispositif de reception de donnees d'information et d'habillage en langage de balisage
US6886166B2 (en) * 2000-09-20 2005-04-26 International Business Machines Corporation Message parsing in message processing systems
US7185081B1 (en) 1999-04-30 2007-02-27 Pmc-Sierra, Inc. Method and apparatus for programmable lexical packet classifier
US7188168B1 (en) 1999-04-30 2007-03-06 Pmc-Sierra, Inc. Method and apparatus for grammatical packet classifier

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5167034A (en) * 1990-06-18 1992-11-24 International Business Machines Corporation Data integrity for compaction devices
US5339421A (en) * 1991-03-22 1994-08-16 International Business Machines Corporation General data stream parser for encoding and decoding data and program interface for same
US5524253A (en) * 1990-05-10 1996-06-04 Hewlett-Packard Company System for integrating processing by application programs in homogeneous and heterogeneous network environments

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5524253A (en) * 1990-05-10 1996-06-04 Hewlett-Packard Company System for integrating processing by application programs in homogeneous and heterogeneous network environments
US5167034A (en) * 1990-06-18 1992-11-24 International Business Machines Corporation Data integrity for compaction devices
US5339421A (en) * 1991-03-22 1994-08-16 International Business Machines Corporation General data stream parser for encoding and decoding data and program interface for same

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998055921A1 (fr) * 1997-06-04 1998-12-10 Telefonaktiebolaget Lm Ericsson Systeme et procede relatifs a une manipulation generique de donnees
AU740953B2 (en) * 1997-06-04 2001-11-15 Telefonaktiebolaget Lm Ericsson (Publ) System and method relating to generic handling of data
GB2327515A (en) * 1997-06-10 1999-01-27 Ibm Message handling
GB2327515B (en) * 1997-06-10 2002-07-17 Ibm Message handling method,message handling apparatus,and memory media for storage a message handling apparatus controlling program
WO1999003036A1 (fr) * 1997-07-11 1999-01-21 Telefonaktiebolaget Lm Ericsson (Publ) Traduction d'appel de procedure a distance
US7185081B1 (en) 1999-04-30 2007-02-27 Pmc-Sierra, Inc. Method and apparatus for programmable lexical packet classifier
US7188168B1 (en) 1999-04-30 2007-03-06 Pmc-Sierra, Inc. Method and apparatus for grammatical packet classifier
US6886166B2 (en) * 2000-09-20 2005-04-26 International Business Machines Corporation Message parsing in message processing systems
WO2004001518A2 (fr) * 2002-06-24 2003-12-31 Koninklijke Philips Electronics N.V. Dispositif de reception de donnees d'information et d'habillage en langage de balisage
WO2004001518A3 (fr) * 2002-06-24 2004-11-25 Koninkl Philips Electronics Nv Dispositif de reception de donnees d'information et d'habillage en langage de balisage

Also Published As

Publication number Publication date
TW305091B (fr) 1997-05-11

Similar Documents

Publication Publication Date Title
US6564265B2 (en) Apparatus for encoding and decoding data according to a protocol specification
US6092118A (en) Inter-computer communication method and apparatus utilizing clocked message playback and message format definition files
US5067104A (en) Programmable protocol engine having context free and context dependent processes
US5608662A (en) Packet filter engine
AU2002234715B2 (en) Method for compressing/decompressing a structured document
Faergemand et al. Introduction to SDL-92
US5418963A (en) Protocol encoding/decoding device capable of easily inputting/referring to a desired data value
FI115416B (fi) Rakenteellisen datan jäsennys
JP7237457B2 (ja) コンピューティング装置
Blumer et al. A formal specification technique and implementation method for protocols
Baker et al. Automatic generation of conformance tests from message sequence charts
US20100211867A1 (en) Processing module, a device, and a method for processing of xml data
Krishnakumar et al. VLSI implementations of communication protocols-a survey
JP2988677B2 (ja) ハイレベルデータリンク制御手順フレームを解析し且つ処理するためのシステム
WO1997008616A1 (fr) Systeme et methode d'analyse et d'elaboration de signaux de donnees
EP0520708B1 (fr) Méthode et appareil pour convertir des syntaxes abstraites de haut niveau en une forme intermédiaire
CN101479969A (zh) 数据封装的方法和设备
KR20040028917A (ko) 정보를 변환하는 통신 제어기 및 방법
CN103246671A (zh) 抽象语法标记文件的处理方法及装置
CN100518177C (zh) 七号信令系统通用解码方法
US20030204638A1 (en) Scripting language for processing typed structured data
JP2996296B2 (ja) メッセージ復号化装置及び有限状態機械生成装置
US20030095310A1 (en) Optical communication apparatus and method
KR100968083B1 (ko) 구조화된 문서들, 특히 ｘｍｌ 문서들을인코딩/디코딩하기 위한 방법 및 장치
d'Auriol et al. COMMAN: a communication analyzer for OCCAM 2

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA CN JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase