Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/06—Message adaptation to terminal or network requirements
  • H04L51/066—Format adaptation, e.g. format conversion or compression
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/21—Monitoring or handling of messages
  • H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/58—Message adaptation for wireless communication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

• MHS Message Handling System
• the invention relates to a system for user support (Message Handling System, MHS) in the handling of information transmissions in a data communication system from one user to another user, in particular also using radio transmission, the application being based on the services of the MHS.
• MHS Message Handling System
• Systems and the MHS system are based on the services of a transport system and the latter directly controls the information transmission devices, which convert the information into a format suitable for the respective transmission link, so that the transmission of protocols is automatically processed and the existing ones are processed by the user Communication means are controlled automatically.
• a so-called Message Handling System supports the user in handling information exchange and communication. It automatically processes the user's send requests and automatically controls the existing communication means.
• the classification of a message handling system in the so-called OSI layer model which in connection with a military data transmission z. B. from the essay by Dietrich Rother, D. Rahlfs, J. Puteick, N. Erbes, D. Roth: "Data transmission for military applications” in the magazine “Wehrtechnik *, Issue 2, 1989, pages 57 to 63 is known, is shown schematically in Figure 1.
• a message handling system MHS is assigned to layers 5 to 7, a transport system TS to layers 1 to 4.
• the application AW relies on the services of the message Handling systems
• the MHS message handling system in turn, relies on the services of the TS transport system.
• the latter directly controls that Data transmission devices DU, which convert the data into a format suitable for the respective transmission link US (wire, radio).
• the control and user information to be transmitted is called the MHS user protocols AP for a message handling system and the TP transport protocols for the TS transport system.
• connection-oriented service It is a very efficient communication profile known as the QMHS or X.400 MHS message handling system. This method is based on a standard on which the OSI layer model mentioned is based.
• This connection is established in layers, i. H.
• Each of the layers 1 to 7 shown in FIG. 1 establishes a connection to the same layer of the remote station, which in turn acknowledges the request to set up.
• This type of transmission is called a connection-oriented service.
• the Message Handling System QMHS or X.400 and its subordinate protocols divide the information and receipts to be transferred into smaller units, ie packets (segmentation). If necessary, the packets belonging to a message can be routed over different routes and nodes. In the receiving system, they are combined again to form a complete message.
• packets Segmentation
• the packets belonging to a message can be routed over different routes and nodes. In the receiving system, they are combined again to form a complete message.
• This processing system based on the OSI standard according to X.400 for data transmission includes not only the characteristics of the "peer-to-peer” protocols but also service elements that are functionally implemented.
• the connection to the transport system is connection-oriented.
• the invention has for its object to achieve a high-performance data communication with other participants, especially when used in a radio circuit, so that despite the presence of an extremely narrow-band transmission medium, the requirements for fast and secure data throughput, especially under the influence of interference, are met.
• There- in the system according to the invention there should additionally be the ability that the priority of a message is taken into account, that the message transmission is acknowledged and that the operational state "radio silence" can be taken into account.
• This object is achieved in a generic system in that only a "peer-to-peer" protocol is provided without a change in direction of the information flow, but full functionality, wherein instead of an acknowledgment sent back by the receiving user, one generated by the transport system of the user sending the information internal receipt for application is provided.
• the protocol overhead which is inevitably associated with the known data transmission methods working with the X.400 system, is avoided, although full functionality is present.
• the information about the successful transmission of the message to the other participant is obtained indirectly from the procedure used by the TransportSystem. This makes the receipt from the other side, which would require a change of direction of the information flow, unnecessary.
• the MHS processing system logically stores a send request from the user to its transport system as one segment or several segments, each of which contains segment header information.
• the segment numbers and the total number of segments are transmitted in the system according to the invention, so that the completeness of a message is recognizable on the part of the receiving user and if an incomplete message transmission is determined, a retransmission of the message segments which have not arrived can be initiated . This can be done several times.
• the "peer-to-peer" protocol is structured in such a way that "peer-to-peer" user data is exchanged with each transmission process and in addition to the user data, minimized header information is sent.
• This header information is binary-coded with regard to dataset identifiers, address information (recipient;, sender), segment number and segment number, creation time, classification, priority, data compression, acknowledgment method, address type, whereby dataset identifiers are used instead of field identifiers include other fields.
• dataset identifiers address information (recipient;, sender), segment number and segment number, creation time, classification, priority, data compression, acknowledgment method, address type, whereby dataset identifiers are used instead of field identifiers include other fields.
• a total of several datasets are defined (currently five datasets), of which only two or three datasets are used per segment.
• an MHS broadcast can advantageously be carried out in addition to the user addresses
• FIG. 1 shows the representation already described in the introduction for the classification of a message handling system (MHS) in the known OSI layer model
• FIG. 3 the acknowledgment and protocol effort between two stations when using the MHS system according to the invention
• FIG. 4 the acknowledgment and protocol effort when using a message handling system according to the invention, but additionally with a user acknowledgment
• FIG. 5 shows the protocol effort when using the MHS system according to the invention for broadcast
• FIG. 6 the protocol effort when using the MHS system according to the invention with group addressing and additionally with user acknowledgment
• FIG. 7 in block diagram form, a functional model of a general message handling system
• FIG. 8 shows application layers of a message handling system in block diagram form
• FIG. 9 the exchange of messages and receipts from a known message handling system
• FIG. 10 shows the form of the application layer in the message handling system according to the invention.
• FIG. 11 shows the point-to-point message exchange and acknowledgments (C S),
• FIG. 12 the echo-free exchange of messages and acknowledgments (CLS),
• FIG. 13 shows a possible assignment of functionality and hardware
• FIG. 14 shows an acknowledgment method for radio (CLS) in block diagram form
• Figure 15 also in block diagram form an acknowledgment method for COS data transmission
• FIG. 16 shows the basic functions of a radio message handling system according to the invention.
• FIGS. 2a, 2b to 6 The differences in the acknowledgment mechanisms when using a known X.400 message handling system and a message handing system constructed in accordance with the invention are shown in detail below with reference to FIGS. 2a, 2b to 6.
• the message handling systems should support the handling of data communication between the participants in a radio network.
• the necessary changes of direction on the radio link are also illustrated in the figures mentioned. Only the protocols and changes of direction are shown above the data link layer.
• the acknowledgment and protocol procedure shown in FIGS. 2a and 2b and which takes place between two stations A and B according to the known X.400 system is already reduced with regard to the acknowledgment measures.
• FIG. 2a shows the transmission of the user data in the direction from station A to station B and
• FIG. 2b the opposite case, namely the transmission of the user data from station B to station A.
• the transmission link US is a radio link in all cases.
• the radio messaging handling system according to the invention does not require any protocol effort for the connection establishment like the X.400 / X.25 systems when using the connectionless service.
• the message (APDü) including the address information is transmitted with a single short transmission.
• the security of the transport system e.g. radio procedure
• a user acknowledgment in the sense of a P2 acknowledgment in the X.400 system only occurs in exceptional cases, e.g. B. for important messages and with a gateway in X.400 systems. This case is shown in detail in FIG. 4.
• the user acknowledgment is labeled AQ, while the message itself is called APDU.
• FIG. 5 shows a broadcast transmission from station A to stations B, C and D via a radio link US.
• a user acknowledgment can be given for group or individual addressing. This case is shown in Figure 6.
• a conventional message handling system supports the asynchronous exchange of information (message transmission with buffers) and is designed for the needs of office communication.
• the system according to the invention has the same basic functionality as the conventional message handling systems, but can be adjusted to additional requirements such as high user data throughput through minimal protocol overhead and minimal changes in radio direction
• connection-oriented (COS), connectionless (CLS) and broadcast transmission types tailored can be used portably and cross-sectionally and allows parallel operation of message handling systems.
• the task of the MHS message handling system is to transmit messages (documents) from one user (user A) to another user (user B).
• the Message Handling System MHS uses the so-called Message Transfer System MTS, which actually transfers messages (messages and receipts) from one place to another.
• This Message Transfer System MTS consists of the so-called Message Transfer Agents MTA.
• the message is transmitted directly from the message transfer agent MTA of user A or B to the message Transfer agent MTA of the other user B or A.
• other message transfer agents MTA can also be involved in the transfer, which pass the messages on to the next message transfer agents MTA.
• the Message Handling System MHS To accept a send order from the user, e.g. B. User A, as well as to deliver the message to the receiving user, e.g. B. User B, the Message Handling System MHS has the so-called User Agents UA.
• User Agents UA In general, several user agents UA can be connected to a message transfer agent MTA, each user agent UA only supporting one user A or B.
• the OSI layer model communication architecture can be roughly broken down into the parts transport profile TP with layers 1 to 4 and application profile AP with layers 5 to 7.
• the radio message handling system FMHS operating in accordance with the invention formally covers layers 6 to 7.
• the application profile AP is divided into three application layers, namely the communication control (layer 5), the presentation layer (layer 6) and the application layer (layer 7).
• the application layer 7 is composed of the functions User Agent UA and Message Transfer Agent MTA already discussed.
• the user agent UA forms the interface to the user, who in the case of an automated system, however, generally communicates with the message handling system via the so-called application AW.
• Below the application layer 7 is the presentation layer 6, which ensures that the exchanged information can also be read in the respective local system.
• each layer exchanges protocol data units with the corresponding layer in the remote system, which units precede the actual content of the message. This results in z. B. separate message header information for the user agent UA and the message transfer agent MTA, although the contents of this header information are partly identical. This is due to the intention that each protocol layer only accesses the specific header information and is therefore independent of the other layers.
• a message is transmitted from one user to another in the known message handling systems, acknowledgments are usually sent back in order to confirm the transmission of the message. If requested, these receipts are generated by the receiving side.
• the form of the mutual exchange of information is determined by protocols.
• the protocol between the Message Transfer Agents MTA is referred to as the PI protocol and that between the User Agents UA as the P2 protocol. Accordingly, the receipt from the Message Transfer Agent MTA is simply called PI receipt and the receipt from User Agent UA as P2 receipt.
• the PI receipt is generated automatically in the system according to the invention, provided that the relevant parameter passed on during the message transmission requires this.
• the P2 receipt is not based on automatism.
• FIG. 9 shows in a block diagram this exchange of messages and receipts from a message handling system between two users A and B.
• the PI and P2 receipts each represent separate messages which are transmitted by the message handling system MHS. Since a user action is required for the P2 acknowledgment, this acknowledgment is therefore not automatically from the message handling system MHS can be generated, it is treated practically like a separate new message and acknowledged with a receipt from the Message Transfer Agent MTA.
• the radio message handling system working according to the invention contains fundamental changes compared to a known message handling system working according to X.400.
• FIG. 10 shows the completely different structure of a radio message handling system working according to the invention in comparison to X.400 systems. Instead of four " peer-to-peer" protocols, the method according to the invention uses only a single "peer-to-peer” protocol that covers the entire functionality.
• a message can be sent to an individual addressee, to a group of recipients and also to all recipients via the radio message handling system operating according to the invention.
• the radio message handling system independently processes the send orders received by the application. If a message is to be sent using the radio message handling system stems FMHS are sent, the send order must state which acknowledgment is expected. Since the FMHS is designed for radio operation, some basic extensions in the acknowledgment procedure are necessary. In the case of wired transmission, an acknowledgment from the message transfer
• Agent MTA can be sent back to the receiving end immediately, this is generally not advisable in radio mode (due to channel access control).
• connection-oriented COS
• CLS connectionless on layer 3-4
• CLS connectionless on layer 3-4
• PI and P2 acknowledgment are adopted for connection-oriented information transmission (COS). This applies especially to wired transmission.
• COS connection-oriented information transmission
• the message header information is greatly reduced. This applies not only to messages, but also to receipts. All receipts (Pl and P2) are optional.
• the generation of receipts is specified on the send side by the application with the send request.
• the echo-laden information transmission is shown schematically in FIG. 11. Since the remote station must respond immediately in the case of echo operation, ie the "echo" EM has to send back, this is only possible in the case of a point-to-point connection. In this case, the correct transmission can be recognized by the receiving side without the receiving side generating a special acknowledgment This means that the quality of this information is almost like a PI receipt. This does not cover the secure transfer from the transport profile to the application profile on the receiving side. This means that if the transfer occurred the last transmission unit of a message M the transfer to the FMHS file system is not possible, the message is not received correctly, but is acknowledged positively. In all other errors, a negative acknowledgment is given.
• This message generated on the transmission side is referred to as “internal transmission confirmation” SB.
• a complete PI acknowledgment is not provided for this case. If necessary, a P2 acknowledgment can also be requested (optional; shown in dashed lines in FIG. 11). But this should can only be used in exceptional cases, since a P2 receipt requires the same transmission time as a smaller message.
• the echo-free information transmission (CLS), which is shown schematically in FIG. 12, can be carried out to one, to several or to all users in a radio circuit. Since the reception side does not send an echo back in this operating mode, only the transmission of the message M to the connected radio device can be determined on the transmission side. This means that only an "internal transfer confirmation" WB is possible. If necessary, a P2 receipt can be requested, as already described (optional; shown in dashed lines in Fig. 12). However, this should only be used in exceptional cases. because a P2 receipt takes the same transmission time as a smaller message.
• FIG. 13 shows the possible assignment of functionality to hardware HW.
• the functionality is divided into three horizontally drawn areas: application AW, application profile AP and transport profile TP.
• the hardware interface runs obliquely between the host computer HR and a communication box CB. This makes it clear what options there are for dividing the functionality into hardware HW.
• the implementation of the application profile AP on the host computer HR represented by the left area of the HW diagram, or the desired solution on the right in the HW diagram with the entire radio message handling FMHS system operating according to the invention on the communication box CB.
• the application profile AP of the radio message handling system (FMHS) can also include further functions or properties in addition to the functionality described above.
• the priority of messages can be taken into account by sending all messages and receipts according to their priority.
• the data compression can be carried out with regard to the message content. This operating mode is specified when the FMHS radio message handling system is initialized. This controls the data compression on the transmission side.
• the receiving side receives the information as to whether it has to perform data decompression or not from the FMHS header information.
• the mode of operation "radio silence" can be specified online by the application. In this case, the FMHS application profile AP stops the internal processing of the send orders and also does not accept any new send orders from the application.
• the radio message handling system FMHS can have universal interfaces to the application, the transport system and the file system, depending on the information, such as displaying the number of send orders or removing a message from the send queue
• the interface is dependent on the implementation case and can be dealt with by a separate module.
• the structure of the core of the FMHS application profile AP is also based on the individual functional units, which are structurally decoupled from other functions as far as possible , Functional expandability of the FMHS application profile AP ensured. Due to the modular internal structure of the FMHS application profile AP, the integration of an encryption method is also technically possible without further ado.
• the following explanations are based on the rough concept of a radio message handling system designed in accordance with the invention and, based on this, represent the individual tasks or functions of this system and the message structure.
• FIG. 14 is expanded by the representation of the message segments MS. It includes both the anechoic and anechoic transmitters.
• the message M arriving from the application AW is broken down into individual message segments MS according to the size. These segments MS are treated by the transport profile TP as individual send orders. This means that each send order is also confirmed by it (internal send confirmation SB or internal forwarding confirmation WB). Since the breakdown of message M into segments MS is transparent to the application, the radio message handling system FMHS collects all segment receipts and then acknowledges the complete message M to the application AW.
• a segment inquiry SN can be initiated if it has been recognized on the receiving side that the message M has not been completely transmitted due to the transmission of the segment numbers and the total number of segments.
• the segment request SN then causes the message segments MS which have not arrived to be retransmitted.
• the P2 receipt shown in dashed lines in FIG. 14 is optional.
• the acknowledgment method for connection-oriented transmission (COS) over wire which is shown schematically in FIG. 15, differs somewhat from the transmission with radio.
• An internal acknowledgment is expediently defined for radio, since acknowledgments from the opposite side are caused by the
• the functions of a radio message handling system in which the principle according to the invention is applied are explained below with reference to FIG. 16.
• the task of such a system is the asynchronous data exchange between the applications on different local systems.
• the send orders are received by the AW application and processed according to various criteria (multiple addressees, priority, repetition, etc.) and finally passed on to the transport system.
• This basic function is referred to in FIG. 16 as “processing send orders”.
• the receive function follows as a second basic function, which is described in the same way as "process receive orders". It accepts the orders from the transport system and forwards them to the application after processing (eg collecting all segments of a message) In addition to messages, receipts are also handed over.
• the transmission function will now be described.
• the tasks of the send function can be divided into three sub-functions:
• a send job is sent to the radio message handling system, it is then determined whether a (configurable) maximum limit of jobs currently being processed has been reached. The number of order segments (message segments and receipts) is appropriately taken into account. If this is the case, no job will be accepted until a (also configurable) minimum limit is undershot.
• the application receives a negative confirmation when the order is submitted to the radio message handling system in the event of an overload. In addition, the radio message handling system sends appropriate management information to the application when one of the limit values is reached.
• the management information required for the radio message handling system is created / created and the order is entered in the radio message handling system (FMHS) logging file.
• FMHS radio message handling system
• the data compression of the user data is carried out if this is specified in the send order.
• the radio message handling system logically stores a send order to the transport system as a segment. These segments are created by the radio message handling system essentially depending on the following parameters: maximum segment size, number of recipients, QOS (broadcast, echo-free, echo-prone). In general, each segment contains a segment header formation. If a message resulted in a segment that is larger than the maximum segment size for the radio message handling system, then this message is broken down into two or more segments according to its size. If a message contains several recipients, in the case of QOS "echo-prone" it is logically broken down internally into several messages, each with only one recipient. This is necessary because the message must be completely transmitted to each of the recipients separate acknowledgment generated. However, the header information of the messages to the individual recipients does not differ. In the case of "broadcast” and "echoless *, the message is sent to all specified recipients at the same time. There is therefore no internal multiplication of the notification.
• Entry of individual orders in the send queue The entry in the send queue completes the sub-function "Preparation of messages and receipts".
• the information in the queue contains additional internal control information in addition to the unambiguous designation of the send segment.
• the entries in the send queue are processed by the radio message handling system taking the priority into account.
• a further criterion is the transmission sequence, which should avoid changing the receiver as far as possible with respect to one radio device in order not to burden the transmission with longer pauses between the segments resulting therefrom.
• a send job with a higher priority arrives, it has priority.
• Messages that have not been successfully acknowledged remain in the send queue until a specified maximum dwell time (configurable) has elapsed in the radio message handling system. Repetitions take place between the normal send jobs, but not before run a repetition period (configurable).
• a new send job is then sent to the transport system in CLS mode if a given order has been positively or negatively acknowledged by the transport system.
• the existence of the corresponding transport connection is checked before the send order to the transport system. If this does not exist, it is set up by the radio message handling system. Depending on the operating mode, the connection can be set up and cleared down for each send job, or it can remain permanently (configurable). All send orders to the transport system or acknowledgments from it are reflected in an update of the internal administration information. All acknowledgments are entered in the radio message handling system (FMHS) log file.
• FMHS radio message handling system
• the following management jobs can be carried out by the application: Search / delete a message from the send queue, radio silence on / off. Updating the radio message handling system operating parameters (not addresses), information about send queues for each priority, output of error messages. All information is passed on to the application or to the network management.
• the tasks of the catch function can be divided into two sub-functions:
• a received message is examined with regard to its type. It can be of the type "message” as well as of the type "Acknowledgment”. This can be determined on the basis of the structure of the message header.
• Internal send confirmations for segments are entered in the send queue. There, it is checked whether the confirmations are available for all segments, in this case a confirmation for a complete message to the application External segment confirmations (COS) are also entered in the send queue. If no PI acknowledgment is expected, this information is used to delete the administrative information. Otherwise, this is only done when the PI acknowledgment arrives. and P2 acknowledgment are passed on to the application All receipts are entered in the radio message handling system (FMHS) log file.
• FMHS radio message handling system
• the received segments of a message are checked for completeness. If this is the case, the message header information can be extracted and the user data from the individual segments can be put together. The receipt of the segment and the forwarding of the complete message are entered in the radio message handling system (FMHS) logging file. The evaluation of the message header shows whether data compression has to be carried out. It is also determined whether a PI receipt must be sent back. If this is the case, a PI receipt is created and placed in the send queue with the priority of the message.
• FMHS radio message handling system
• the radio message handling system receives messages of various sizes from the application. In order to achieve secure transmission of information, this information is generally broken down into smaller subunits before it is physically is transmitted. This means that in the event of transmission errors, a smaller amount of information and not the complete message must be repeated. If the transmission path is disturbed for a certain time, the transmission of the data on the transport layer is interrupted. In order to still be able to transmit a message, the radio message handling system tries to send further messages that cover a larger time frame. This significantly increases the likelihood of a successful transmission. Compared to larger information units, smaller units perform better in terms of the transmission probability under interference. For this reason, the radio message handling system has the option of splitting larger messages into so-called message segments.
• the radio message handling system is a component of an overall system. It swaps with others Components such as the application and the transport system data. Since each component has finite data throughput, which differs from component to component, the data flow must be regulated. To adapt to changing data throughput, the radio message handling system as well as the transport system has a job queue in which, if the send jobs are temporarily overpaid, they can be stored temporarily until they are processed. The fill level of the job queue is therefore used to control the data throughput. With regard to the application interface, this means that messages of low priority are only accepted to a certain extent. If messages of higher priority now arrive, they can be accepted without restriction. Another advantage is the minimization of administrative information.
• a maximum dwell time of the messages can be set in the radio message handling system. If the number of messages transferred to the radio message handling system were continuously increased without flow control, a condition would inevitably be reached in which a message could no longer be sent in the specified time frame due to the finite throughput of the transport system. In this case, a send order, since it cannot be finally processed in the specified time frame, would only unnecessarily increase the management information of the system and impair efficiency. If the application has a possibility at the same time, in the event that the send orders are rejected by the
• radio message handling system displays this system status to the user, he can also react to it in a suitable manner.
• radio message handling system Before the radio message handling system changes to the operational operating state, all configuration parameters must first be determined from the corresponding configuration files. will read. If there is no radio message handling system (FMHS) logging file, a new one is created. This allows the application to create a new radio message handling system logging file before each start, if desired. Since the radio message handling system stores all parameters relevant to the processing status on the hard disk of the computer, it can be restarted from this information at exactly the point where it was canceled. If a restart without restart is necessary, the application can delete all information in the work area of the radio message handling system before the radio message handling system restart.
• FMHS radio message handling system
• the radio message handling system message consists of the header information and the user data.
• the header information is binary coded to minimize the amount of data to be transmitted, except for the specification of the message ID.
• the structure of the radio message handling system receipt largely corresponds to the structure of the message. Only the user data portion is not available. Since the binary header information contains different parameters that have to be identified, special labels are used. In order not to have to specify these for each parameter, however, according to an advantageous development of the invention, various parameters are combined into so-called data fields in accordance with their occurrence in the header information. Only each data field contains an identifier. At the same time, it is ensured that until the last possible data field occurs, the data field identification cannot occur via a parameter value in the header information. In order to minimize the amount of data, the data field identifier advantageously consists of only one byte.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Communication Control (AREA)
• Computer And Data Communications (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=7802287

Family Applications (1)

Country Status (4)

Families Citing this family (3)

Family Cites Families (2)

• 1996
  • 1996-08-09 DE DE19632258A patent/DE19632258C1/de not_active Expired - Fee Related
• 1997
  • 1997-08-08 WO PCT/DE1997/001688 patent/WO1998007260A1/de not_active Application Discontinuation
  • 1997-08-08 EP EP97936607A patent/EP0968595A1/de not_active Withdrawn
• 1999
  • 1999-02-08 NO NO990576A patent/NO990576L/no unknown

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events