EP0968595A1 - System zur anwenderunterstützung (message handling system, mhs) bei der abwicklung von informationsübertragungen in einem daten-kommunikationssystem - Google Patents

System zur anwenderunterstützung (message handling system, mhs) bei der abwicklung von informationsübertragungen in einem daten-kommunikationssystem

Info

Publication number
EP0968595A1
EP0968595A1 EP97936607A EP97936607A EP0968595A1 EP 0968595 A1 EP0968595 A1 EP 0968595A1 EP 97936607 A EP97936607 A EP 97936607A EP 97936607 A EP97936607 A EP 97936607A EP 0968595 A1 EP0968595 A1 EP 0968595A1
Authority
EP
European Patent Office
Prior art keywords
message
user
information
transmission
radio
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP97936607A
Other languages
English (en)
French (fr)
Inventor
Wolfgang Kamphausen
Andreas Kratzer
Gerhard Ossiander
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Daimler AG
Original Assignee
DaimlerChrysler AG
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 DaimlerChrysler AG filed Critical DaimlerChrysler AG
Publication of EP0968595A1 publication Critical patent/EP0968595A1/de
Withdrawn legal-status Critical Current

Links

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)

Abstract

Nach der Erfindung setzt die Anwendung auf den Diensten des MHS-Abwicklunssystems und das MHS-Abwicklungssystem wiederum auf den Diensten eines Transportsystems auf, wobei letzteres direkt die Informationsübertragungseinrichtungen ansteuert, welche die Informationen in ein für die jeweilige Übertragungsstrecke geeignetes Format umsetzen, so daß unter Übertragung von Protokollen die Anwendersendeaufträge automatisch bearbeitet und die vorhandenen Kommunikationsmittel selbsttätig gesteuert werden. Dabei wird nur ein 'peer-to-peer'-Protokoll ohne Richtungswechsel des Informationsflusses, jedoch voller Funktionalität verwendet, wobei anstelle einer vom empfangenden Benutzer rückgesendeten Quittung eine vom Transportsystem des die Information aussendenden Benutzers generierte interne Quittung zur Anwendung hin vorgesehen ist. Das Message Handling System (MHS) nach der Erfindung ist insbesondere zur leistungsstarken und schnellen Datenkommunikation vor allem verhältnismäßig kurzer Mitteilungen in einem Funknetz einsetzbar.

Description

Beschreibung
System zur Anwenderunterstützung (Message Handling System. MHS) bei der Abwicklung von Informationsübertragungen in ei- ne Daten-Kommunikationssyste
Die Erfindung bezieht sich auf ein System zur Anwenderunterstützung (Message Handling System, MHS) bei der Abwicklung von Informationsübertragungen in einem Daten- Kommunikationssystem von einem Benutzer zu einem anderen Benutzer, insbesondere auch unter Verwendung von Funkübertragung, wobei die Anwendung auf den Diensten des MHS-Systems und das MHS-System wiederum auf den Diensten eines Transport- Systems aufsetzt und letzteres direkt die Informationsüber- tragungseinrichtungen ansteuert, welche die Informationen in ein für die jeweilige Obertragungsstrecke geeignetes Format umsetzen, so daß unter Übertragung von Protokollen die Anwendersendeaufträge automatisch bearbeitet und die vorhandenen Kommunikationsmittel selbsttätig gesteuert werden.
Ein sogenanntes Message Handling System (MHS) unterstützt den Anwender bei der Abwicklung des Informationsaustausches und der Kommunikation. Es bearbeitet die Sendeaufträge des Anwenders automatisch und steuert selbsttätig die vorhandenen Korπtπmunikationsmittel . Die Einordnung eines Message Handling Systems in das sogenannte OSI-Schichtenmodell, das in Verbindung mit einer militärischen Datenübertragung z. B. aus dem Aufsatz von Dietrich Rother, D. Rahlfs, J. Puteick, N. Erbes, D. Roth: „Datenübertragung für militärische Anwendungen" in der Zeitschrift „Wehrtechnik*, Heft 2, 1989, Seiten 57 bis 63 bekannt ist, ist in Figur 1 schematisch dargestellt. In diesem OSI-Schichtenmodell ist ein Message Handling System MHS den Schichten 5 bis 7, ein Transportsystem TS den Schichten 1 bis 4 zugeordnet. Im Sinne dieses Modells setzt die Anwendung AW auf die Dienste (Services) des Message Handling Systems
MHS, das Message Handling System MHS wiederum auf die Dienste des Transportsystems TS auf. Das letztere steuert direkt die Datenübertragungseinrichtungen DU an, welche die Daten in ein für die jeweilige Übertragungsstrecke US (Draht, Funk) geeignetes Format umsetzen. Die zu übertragenden Steuer- und Nutzinformationen werden bei einem Message Handling System MHS Anwenderprotokolle AP und für das TransportSystem TS Transportprotokolle TP genannt.
Zur Erlangung des Komforts eines Message Handling Systems MHS ist eine Reihe von Steuerinformationen erforderlich, die teilweise vom TransportSystem TS mit übertragen werden müssen und die Übertragungsstrecke US zusätzlich belegen. Je komplexer eine Netzstruktur ist, desto aufwendiger müssen diese Steuerinformationen sein.
Es ist ein sehr effizientes Kommunikationsprofil, das sogenannte Message Handling System QMHS bzw. X.400 MHS bekannt. Dieses Verfahren beruht auf einer Norm, der das erwähnte OSI- Schichtenmodell zugrundeliegt. Dabei wird vor der eigentlichen Meldungsübertragung zur Gegenstation ein sogenannter Verbindungsaufbau durchgeführt, um zu gewährleisten, daß die physikalische und logische Verbindung zwischen den Rechnern vor der eigentlichen Meldungsübertragung hergestellt ist. Dieser Verbindungsaufbau erfolgt schichtenweise, d. h. jede der in Figur 1 aufgeführten Schichten 1 bis 7 baut eine Ver- bindung zur gleichen Schicht der Gegenstelle auf, die den Aufbauwunsch wiederum quittiert . Diese Art der Übertragung wird als verbindungsorientierter Dienst bezeichnet .
Das Message Handling System QMHS bzw. X.400 und ihre unterla- gerten Protokolle teilen die zu übertragenden Informationen und Quittungen in kleinere Einheiten, d. h. Pakete, auf (Segmentierung) . Die zu einer Meldung gehörenden Pakete können gegebenenfalls über verschiedene Strecken und Knoten geleitet werden. Im Empfangssystem werden sie wieder zu einer kompletten Meldung zusammengebunden (assembliert) . Bei Übertragung von normalen Meldungen von z. B. 100 bis 10000 Zeichen Nutzinformation müssen ca. 1800 bis 2600 Byte Steuerinfor ation, je nach gewünschtem Quittierungsmechanis- mus, mit über die Übertragungsstrecke übertragen werden. Hier ist ersichtlich, daß bei sehr kleinen Meldungen ein ungünstiges Verhältnis von Nutz- zu Steuerinformation entsteht. Bei komplexen Netzen muß diese Tatsache in Kauf genommen werden.
Dieses auf der OSI-Norm beruhende Abwicklungssystem nach X.400 zur Datenübertragung umfaßt neben der Ausprägung der „peer-to-peer"-Protokolle also auch Service-Elemente, die funktional realisiert werden. Die Anbindung an das Transport- system erfolgt verbindungsorientiert .
Bei diesem bekannten System entsteht der Nachteil, daß aufgrund des erforderlichen Austauschs von Daten über eine Vielzahl von „peer-to-peer"-Protokollen und den ebenfalls notwendigen Richtungswechsel des Informationsflusses der Datendurchsatz nicht den erforderlichen Wert erreicht. Bei Anwen- düng einer Datenkommunikation mit anderen Teilnehmern in einem Funkkreis werden außerdem funkspezifische Teilfunktionen wie „Broadcast" oder „Funkstille" nicht unterstützt.
Aus dem Amateurfunkbereich ist die sogenannte Amateurfunkpro- zedur AX-25 bekannt, wonach eine Mitteilung sofort über das jeweilige Funkgerät ausgesendet wird. Hierbei entsteht der Nachteil, daß dieses Verfahren aufgrund des Fehlens von übergeordneten Maßnahmen zur Sicherstellung der Datenübertragung bei länger andauernden Störeinflüssen nur bei idealen Funkbe- dingungen eingesetzt werden kann.
Der Erfindung liegt die Aufgabe zugrunde, eine leistungsstarke Datenkommunikation mit anderen Teilnehmern insbesondere bei Einsatz in einem Funkkreis zu erreichen, so daß trotz Vorliegens eines extrem schmalbandigen Übertragungsmediums die Anforderungen an einen schnellen und sicheren Datendurchsatz, insbesondere unter Störungseinfluß, erfüllt werden. Da- bei soll beim erfindungsgemäßen System zusätzlich die Fähigkeit bestehen, daß die Priorität einer Mitteilung berücksichtigt wird, daß die Mitteilungsübertragung quittiert wird und daß der operationelle Zustand „Funkstille" berücksichtigt werden kann.
Diese Aufgabe wird bei einem gattungsgemäßen System dadurch gelöst, daß nur ein „peer-to-peer"-Protokoll ohne Richtungswechsel des Informationsflusses, jedoch voller Funktionalität vorgesehen ist, wobei anstelle einer vom empfangenden Benutzer rückgesendeten Quittung eine vom Transportsystem des die Information aussendenden Benutzers generierte interne Quittung zur Anwendung hin vorgesehen ist .
Beim System nach der Erfindung wird das Protokoll-Overhead, das mit den bekannten mit X.400-System arbeitenden Datenübertragungsverfahren zwangsläufig verbunden ist, vermieden, wobei jedoch volle Funktionalität vorliegt. Die Information über die erfolgreiche Übertragung der Mitteilung an den ande- ren Teilnehmer wird indirekt aus dem Verfahren, das vom TransportSystem angewendet wird, gewonnen. Damit wird die Quittung von der Gegenseite, was einen Richtungswechsel des Informationsflusses erforderlich machen würde, unnötig.
Eine sogenannte Wiederaufsetzfunktion wird in dem erwähnten „peer-to-peer* -Protokoll abgedeckt. Ein Sendeauftrag des Benutzers an sein TransportSystem wird vom MHS-Abwicklungssy- ste logisch als ein Segment oder mehrere Segmente abgelegt, die jeweils eine Segment-Kopfinformation enthalten. Die Seg- ment-Nummern und die Gesamtsegmente-Anzahl werden beim System nach der Erfindung übertragen, so daß auf seiten des empfangenden Benutzers die Vollständigkeit einer Mitteilung erkennbar ist und sich bei Feststellung einer unvollständigen Mitteilungsübertragung eine nochmalige Übertragung der nicht an- gekommenen Mitteilungssegmente veranlassen läßt. Dies kann mehrmals erfolgen. Grundsätzlich ist das „peer-to-peer"-Protokoll so aufgebaut, daß mit jedem Sendevorgang „peer-to-peer"-Nutzdaten ausgetauscht werden und zusätzlich zu den Nutzdaten eine minimierte Kopfinformation gesendet wird. Diese Kopfinformation ist hinsichtlich Dataset-Bezeichnern, Adreßinformationen (Empfänger;, Absender), Segment-Nummer und Segmente-Anzahl, Erstellzeit, Klassifizierung, Priorität, Datenkompression, Quittierungsverfahren, Adreßtyp binärcodiert, wobei anstelle von Feld-Bezeichnern Dataset-Bezeichner verwendet werden, die andere Felder umfassen. Zwar sind insgesamt mehrere Datasets definiert (zur Zeit fünf Datasets) , von denen aber pro Segment nur zwei oder drei Datasets genutzt werden.
In vorteilhafter Weise läßt sich beim System nach der Erfin- düng zusätzlich zu den Benutzeradressen eine MHS-Broadcast
(Rundsendung „an alle") -Adresse definieren, die grundsätzlich dann eingetragen wird, wenn von einem Benutzer eine Mitteilung „an alle" gesendet werden soll. Die Transportadresse dazu ist frei konfigurierbar.
Beim System nach der Erfindung ist außerdem die Vorgabe einer „Funkstille" -Funktion möglich, bei der lediglich Mitteilungen empfangen, aber nicht gesendet werden können.
Im folgenden wird das System nach der Erfindung anhand von 16 Figuren erläutert . Es zeigen
Figur 1 die bereits einleitend geschilderte Darstellung zur Einordnung eines Message Handling Systems (MHS) in das be- kannte OSI-Schichtenmodell,
Figuren 2a und 2b den Quittierungs- und Protokollaufwand zwischen zwei Stationen bei einem Verbindungsorientierten Dienst mit dem bekannten System X.400 über eine Funkstrecke,
Figur 3 den Quittierungs- und Protokollaufwand zwischen zwei Stationen bei Anwendung des MHS-Systems nach der Erfindung, Figur 4 den Quittierungs- und Protokollaufwand bei Anwendung eines Message Handling Systems nach der Erfindung, allerdings zusätzlich mit -Anwenderquittung,
Figur 5 den Protokollaufwand bei Anwendung des MHS-Systems nach der Erfindung bei Broadcast,
Figur 6 den Protokollaufwand bei Anwendung des MHS-Systems nach der Erfindung mit Gruppenadressierung und zusätzlich mit Anwenderquittierung,
Figur 7 in Blockschaltbildform ein funktionales Modell eines allgemeinen Message Handling Systems,
Figur 8 in Blockschaltbildform Anwendungsschichten eines Message Handling Systems,
Figur 9 den Austausch von Mitteilungen und Quittungen eines bekannten Message Handling Systems,
Figur 10 die Ausprägung der Anwendungsschicht beim Message Handling System nach der Erfindung,
Figur 11 den Punkt-zu-Punkt-Meldungsaustausch und Quittierungen (C S) ,
Figur 12 den echolosen Austausch von Mitteilungen und Quittierungen (CLS) ,
Figur 13 die Darstellung einer möglichen Zuordnung von Funktionalität und Hardware,
Figur 14 in Blockschaltbildform ein Quittierungsverfahren für Funk (CLS), Figur 15 ebenfalls in Blockschaltbildform ein Quittierungsverfahren für die COS-Datenübertragung und
Figur 16 eine Darstellung der Grundfunktionen eines Funk- Message Handling Systems nach der Erfindung.
Anhand der Figuren 2a, 2b bis Figur 6 werden im folgenden detailliert die Unterschiede der Quittungsmechanismen bei Einsatz eines bekannten, nach dem System X.400-Message Handling Systems und eines entsprechend der Erfindung aufgebauten Message Handlimg Systems aufgezeigt. In allen Fällen sollen die Message Handling Systeme die Abwicklung der Datenkommunikation zwischen den Teilnehmern in einem Funknetz unterstützen. In den genannten Figuren sind auch die notwendigen Richtungs- Wechsel auf der Funkstrecke verdeutlicht . Es werden hierbei nur die Protokolle und Richtungswechsel oberhalb der Sicherungsschicht dargestellt. Das in den Figuren 2a und 2b gezeigte und zwischen zwei Stationen A und B gemäß dem bekannten X.400-System ablaufende Quittierungs- und Protokollver- fahren ist bereits hinsichtlich der Quittierungsmaßnahmen reduziert. Figur 2a zeigt die Aussendung der Nutzdaten in Richtung von der Station A zur Station B und Figur 2b den entgegengesetzten Fall, nämlich die Aussendung der Nutzdaten von der Station B zur Station A. Die Übertragungsstrecke US ist in allen Fällen eine Funkstrecke.
Das Funk-Messsage Handling System nach der Erfindung (Fig. 3 bis 6) benötigt bei Verwendung des verbindungslosen Dienstes dagegen keinen Protokollaufwand für den Verbindungsaufbau wie die X.400/X.25-Systeme. Im Normalfall wird bei Anwendung des Systems nach der Erfindung die Meldung (APDü) einschließlich der Adreßinformation mit einer einzigen kurzen Sendung übertragen. Die Sicherung des TransportSystems (z. B. Funkprozedur) übergibt dem Funk-Message Handling System eine interne Sendebestätigung), die in Figur 3 mit ÜI bezeichnet ist. Eine Anwenderquittung im Sinne einer P2-Quittung im X.400-System erfolgt nur in Ausnahmefällen, z. B. bei wichtigen Meldungen und bei einem Netzübergang in X.400-Systeme. Dieser Fall ist in Figur 4 im einzelnen dargestellt. Die Anwenderquittung ist hierbei mit AQ bezeichnet, während die Meldung selbst die Bezeichnung APDU trägt .
Bei Broadcast-Sendungen »an alle" entfällt die Anwenderquittung. Figur 5 zeigt in diesem Zusammenhang eine Broadcast- Sendung von einer Station A zu Stationen B, C und D über eine Funkstrecke US. Bei Gruppen- oder Einzeladressierung kann ei- ne Anwenderquittung erfolgen. Dieser Fall ist in Figur 6 aufgezeigt .
Ein herkömmliches Message Handling System unterstützt den asynchronen Informationsaustausch (Meldungsübermittlung mit Zwischenspeichern) und ist auf die Bedürfnisse der Bürokommunikation ausgelegt. Das System nach der Erfindung hat die gleiche Grundfunktionalität wie die herkömmlichen Message Handling Systeme, ist jedoch auf zusätzliche Anforderungen wie hohen Nutzdatendurchsatz durch minimalen Protokoll- Overhead und minimale Funkrichtungswechsel, einstellbare
Quittierungen, Verbindungsorientierte (COS) , verbindungslose (CLS) und Broadcast-Übertragungsarten zugeschnitten, ist portierbar und querschnittlieh einsetzbar und gestattet einen parallelen Betrieb von Message Handling Systemen.
Anhand von Figur 7 wird im folgenden ein funktionales Modell eines allgemeinen Message Handling Systems erläutert. Die Aufgabe des Message Handling Systems MHS ist das Übermitteln von Mitteilungen (Dokumenten) von einem Benutzer (Benutzer A) zu einem anderen Benutzer (Benutzer B) . Das Message Handling System MHS bedient sich dazu des sogenannten Message Transfer Systems MTS, das die eigentliche Übertragung von Meldungen (Mitteilungen und Quittungen) von einem Ort zum anderen vornimmt. Dieses Message Transfer System MTS besteht aus den so- genannten Message Transfer Agents MTA. Im einfachsten Fall erfolgt die Übertragung der Meldung direkt von dem Message Transfer Agent MTA eines Benutzers A oder B zum Message Transfer Agent MTA des anderen Benutzers B bzw. A. Generell können an der Übertragung noch weitere Message Transfer Agents MTA beteiligt sein, welche die Meldungen den nächsten Message Transfer Agents MTA weiterreichen.
Zur Annahme eines Sendeauftrags vom Benutzer, z. B. Benutzer A, wie auch zur Auslieferung der Mitteilung an den empfangenden Benutzer, z. B. Benutzer B, verfügt das Message Handling System MHS über die sogenannten User Agents UA. Allgemein können mehrere User Agents UA an einem Message Transfer Agent MTA angeschlossen sein, wobei jeder User Agent UA jeweils nur einen Benutzer A oder B unterstützt.
Die OSI-Schichtenmodell-Kommunikationsarchitektur kann grob in die Anteile Transportprofil TP mit den Schichten 1 bis 4 und Anwendungsprofil AP mit den Schichten 5 bis 7 zerlegt werden. Das gemäß der Erfindung arbeitende Funk-Message Handling System FMHS deckt formal die Schichten 6 bis 7 ab. Wie in Figur 8 im einzelnen dargestellt ist, gliedert sich das Anwendungsprofil AP in drei Anwendungsschichten, nämlich in die Kommunikationssteuerung (Schicht 5), die Darstellungsschicht (Schicht 6) und die Anwendungsschicht (Schicht 7) . Die Anwendungsschicht 7 setzt sich aus den schon besprochenen Funktionen User Agent UA und Message Transfer Agent MTA zu- sammen. Der User Agent UA bildet die Schnittstelle zum Benutzer, der im Falle eines automatisierten Systems jedoch in der Regel über die sogenannte Anwendung AW mit dem Message Handling System kommuniziert. Unterhalb der AnwendungsSchicht 7 folgt die Darstellungsschicht 6, welche sicherstellt, daß die ausgetauschte Information im jeweiligen lokalen System auch gelesen werden kann. Da sich die Darstellung der Information von System zu System unterscheiden kann, erfolgt der Informationsaustausch über eine sogenannte Transfersyntax. Die Kommunikationssteuerung in der Schicht 5 schließlich sorgt für die gesicherte Übertragung der Information. Sie erlaubt es, nach Abbruch der Übertragung von Mitteilungen genau an dieser Stelle mit der Übertragung fortzufahren, ohne Information zu verlieren, bzw. sie vermeidet, Information mehrfach zu übertragen. Zudem gestattet sie es, Informationen mit höherer Priorität zu übertragen. Bei den bekannten Message Handling Systemen tauscht dazu jede Schicht mit der korrespondierenden Schicht im entfernten System Protokolldateneinheiten aus, die dem eigentlichen Inhalt der Mitteilung vorangestellt werden. Damit ergibt sich z. B. eine separate Meldungskopfinformation für den User Agent UA und den Message Transfer Agent MTA, obwohl Inhalte dieser Kopfinformationen zum Teil identisch sind. Dies ist bedingt durch die Absicht, daß jede Protokollschicht nur auf die spezifische Kopfinformation zugreift und damit von den anderen Schichten unabhängig ist .
ird bei den bekannten Message Handling Systemen eine Mittei- lung von einem Benutzer zum anderen übertragen, so werden in der Regel wiederum Quittungen zurückgesendet, um die Übertragung der Mitteilung zu bestätigen. Diese Quittungen werden, sofern angefordert, von der Empfangsseite erzeugt. Die Form des gegenseitigen Informationsaustausches ist durch Protokol- le festgelegt. Das Protokoll zwischen den Message Transfer Agents MTA wird als Pl-Protokoll bezeichnet und das zwischen den User Agents UA als P2-Protokoll . Entsprechend bezeichnet man die Quittung vom Message Transfer Agent MTA vereinfacht als Pl-Quittung und die Quittung vom User Agent UA als P2- Quittung. Die Pl-Quittung wird beim System nach der Erfindung automatisch erzeugt, sofern der bei der Meldungsübertragung mit übergebene diesbezügliche Parameter dieses verlangt. Der P2-Quittung liegt kein Automatismus zugrunde. Der User Agent UA bietet lediglich den Dienst an, vom Nutzer neben dem Auf- trag »Sendemitteilung" auch den Auftrag „Sendequittung" anzunehmen. Figur 9 zeigt in einem Blockschaltbild diesen Austausch von Mitteilungen und Quittungen eines Message Handling Systems zwischen zwei Benutzern A und B. Die PI- und P2- Quittungen stellen jeweils eigene Meldungen dar, die vom Mes- sage Handling System MHS übertragen werden. Da für die P2- Quittung eine Benutzeraktion erforderlich ist, und diese Quittung somit nicht automatisch vom Message Handling System MHS erzeugt werden kann, wird sie praktisch wie eine eigene neue Mitteilung behandelt und mit einer Empfangsbestätigung vom Message Transfer Agent MTA quittiert.
Das nach der Erfindung arbeitende Funk-Message Handling System enthält grundlegende Änderungen gegenüber einem nach X.400 arbeitenden bekannten Message Handling System.
Um den Protokoll-Overhead zu verringern, wird die Funktiona- lität von User Agent UA und Message Transfer Agent MTA zu einer Funktionseinheit zusammengefaßt. Da nur jeweils eine Schnittstelle zur Anwendung erforderlich ist, ergeben sich daraus keinerlei Nachteile. Anstatt separater UA- und MTA- Meldungskopfinformationen wird damit also nur eine Meldungs- köpfinformation übertragen. Zusätzlich wird auch die in dieser Kopfinformation enthaltene Information so kompakt wie möglich aufgebaut. Auf die Ausbildung einer Darstellungsschicht 6 wird verzichtet. Die Kommunikationssteuerung in der Schicht 5 ist für kurze Mitteilungen nicht notwendig. Längere Mitteilungen werden jedoch in Segmente zerlegt und einzeln an die Transportschicht übergeben. Für die damit einhergehende Verwaltung der Meldungsübertragung ist sie ebenso nötig. Die Kommunikationssteuerung in der Schicht 5 wird beim System nach der Erfindung ebenfalls in das Anwendungsprofil inte- griert. Figur 10 zeigt die gänzlich unterschiedliche Struktur eines nach der Erfindung arbeitenden Funk-Message Handling Systems im Vergleich zu X.400-Systemen. Anstatt vier »peer- to-peer" -Protokollen wird beim Verfahren nach der Erfindung nur ein einziges „peer-to-peer" -Protokoll eingesetzt, das die gesamte Funktionalität abdeckt.
Eine Mitteilung kann über das gemäß der Erfindung arbeitende Funk-Message Handling System an einen Einzeladressaten, an eine Gruppe von Empfängern und auch an alle Empfänger gesen- det werden. Dabei arbeitet das Funk-Message Handling System die von der Anwendung erhaltenen Sendeaufträge selbständig ab. Soll eine Meldung mittels des Funk-Message Handling Sy- stems FMHS versendet werden, so muß im Sendeauftrag angegeben sein, welche Quittierung erwartet wird. Da das FMHS für den Funkbetrieb ausgelegt ist, sind einige grundlegende Erweiterungen im Quittierungsverfahren notwendig. Während bei draht- gebundener Übertragung eine Quittung vom Message Transfer
Agent MTA der Empfangsseite sofort wieder zurückgesendet werden kann, ist dies im Funkbetrieb in der Regel nicht zweckmäßig (wegen Kanalzugriffsregelung) .
Grundsätzlich sind drei verschiedene Übertragungsarten möglich, nämlich a) verbindungsorientiert (COS) , b) verbindungslos auf Schicht 3-4 (CLS) - echobehaftet auf Schicht 2 - und c) verbindungslos auf Schicht 3-4 (CLS) - echolos auf Schicht 2. Im folgenden werden die jeweiligen Quittierungsverfahren erläutert.
a) Für die Verbindungsorientierte Informationsübertragung (COS) werden die beiden Quittierungsarten (PI- und P2- Quittung) prinzipiell übernommen. Dies gilt speziell für die drahtgebundene Übertragung. Bei Anwendung des Systems nach der Erfindung wird die Meldungskopfinformation stark reduziert. Dies gilt nicht nur für Mitteilungen, sondern auch für die Quittungen. Alle Quittungen (Pl und P2) sind optional. Die Erzeugung von Quittungen wird sendeseitig von der Anwen- düng mit dem Sendeauftrag spezifiziert.
b) Die echobehaftete Informationsübertragung (CLS) ist in Figur 11 schematisch dargestellt. Da beim echobehafteten Betrieb die Gegenstelle sofort antworten muß, d. h. das „Echo" EM zurücksenden muß, ist dies nur im Falle einer Punkt-zuPunkt-Verbindung möglich. Ohne daß die Empfangsseite eine spezielle Quittung generiert, kann in diesem Fall die korrekte Übertragung sendeseitig erkannt werden. Damit kommt diese Information qualitativ fast einer Pl-Quittung gleich. Ledig- lieh die sichere Übertragung vom Transportprofil zum Anwendungsprofil auf der Empfangsseite wird dadurch nicht abgedeckt . Dies bedeutet, daß, falls im Moment der Übertragung der letzten Übertragungseinheit einer Mitteilung M die Weitergabe zum FMHS-Dateisystem nicht möglich ist, die Meldung nicht korrekt empfangen, jedoch positiv quittiert wird. In allen anderen Fehlerfällen wird eine negative Quittung gege- ben. Diese sendeseitig erzeugte Meldung wird als „interne Sendebestätigung" SB bezeichnet. Eine komplette Pl-Quittung ist für diesen Fall nicht vorgesehen. Falls erforderlich, kann auch eine P2-Quittung angefordert werden (optional; in Fig. 11 gestrichelt dargestellt) . Dies sollte aber nur in Ausnahmefällen genutzt werden, da eine P2-Quittung die gleiche Übertragungszeit benötigt wie eine kleinere Mitteilung.
c) Die echolose Informationsübertragung (CLS) , die in Figur 12 schematisch dargestellt ist, kann an einen, an mehrere oder an alle Benutzer in einem Funkkreis erfolgen. Da die -Empfangsseite in dieser Betriebsart kein Echo zurücksendet, kann sendeseitig nur die erfolgte Weitergabe der Mitteilung M an das angeschlossene Funkgerät festgestellt werden. Es ist also damit nur eine „interne Weitergabebestätigung" WB mög- lieh. Falls notwendig, kann, wie bereits beschrieben, eine P2-Quittung angefordert werden (optional; in Fig. 12 gestrichelt dargestellt) . Dies sollte aber nur in Ausnahmefällen genutzt werden, da eine P2-Quittung die gleiche Übertragungszeit benötigt wie eine kleinere Mitteilung.
Die Darstellung in Figur 13 zeigt die mögliche Zuordnung von Funktionalität zur Hardware HW. Die Funktionalität gliedert sich in die drei horizontal eingezeichneten Bereiche: Anwendung AW, Anwendungsprofil AP und Transportprofil TP. Schräg dazu verläuft die Hardware-Schnittstelle zwischen dem Host- Rechner HR und einer Kommunikations-Box CB. Damit wird deutlich, welche Möglichkeiten zur Aufteilung der Funktionalität zur Hardware HW besteht. Die Implementierung des Anwendungsprofils AP auf den Host-Rechner HR, repräsentiert durch den linken Bereich des HW-Diagra ms , oder die angestrebte Lösung rechts im HW-Diagramm mit dem gesamten Funk-Message Handling System FMHS, das gemäß der Erfindung arbeitet, auf der Kommunikations-Box CB.
Das Anwendungsprofil AP des Funk-Message Handling Systems (FMHS) nach der Erfindung kann noch weitere Funktionen bzw. Eigenschaften in Ergänzung zu der vorher dargestellten Funktionalität umfassen. Es läßt sich die Priorität von Mitteilungen berücksichtigen, indem alle Mitteilungen und Quittungen entsprechend ihrer Priorität gesendet werden. Im FMHS- Anwendungsprofil AP kann die Datenkompression bezüglich des Mitteilungsinhalts durchgeführt werden. Diese Betriebsart wird bei der Initialisierung des Funk-Message Handling Systems FMHS vorgegeben. Damit wird die Datenkompression sendeseitig gesteuert. Die Empfangsseite hingegen erhält die In- formation, ob sie eine Datendekompression durchführen muß oder nicht, aus der FMHS-Kopfinformation. Von der Anwendung kann die Betriebsart „Funkstille" online vorgegeben werden. In diesem Fall stoppt das FMHS-Anwendungsprofil AP die interne Bearbeitung der Sendeaufträge und nimmt zudem von der An- wendung keine neuen Sendeaufträge entgegen. Es sind auch Eingriffsmöglichkeiten dahingehend durchführbar, interne FMHS- Infor ationen wie z. B. die Anzahl der Sendeaufträge anzuzeigen oder eine Mitteilung aus der Sendewarteschlange zu entfernen. Das Funk-Message Handling System FMHS nach der Erfin- düng kann über universelle Schnittstellen zur Anwendung, zum Transportsystem und zum Dateisystem verfügen. Die jeweilige Ausprägung der Schnittstelle ist vom Implementierungsfall abhängig und läßt sich jeweils durch einen separaten Modul abhandeln. Der Aufbau des Kerns des FMHS-Anwendungsprofils AP orientiert sich ebenfalls an den einzelnen Funktionseinheiten, die jeweils von anderen Funktionen soweit als möglich strukturell entkoppelt werden. Damit wird eine entsprechend einfache, funktionale Erweiterungsfähigkeit des FMHS-Anwendungsprofils AP sichergestellt. Aufgrund des modularen inter- nen Aufbaus des FMHS-Anwendungsprofils AP ist auch die Integration eines Verschlüsselungsverfahrens technisch ohne weiteres möglich. Die folgenden Ausführungen basieren auf dem Grobkonzept eines entsprechend der Erfindung ausgebildeten Funk-Message Handling Systems und stellen, darauf aufbauend, die einzelnen Aufgaben bzw. Funktionen dieses Systems sowie die Meldungsstruktur dar.
Zunächst wird das Quittierungsverfahren für Funk (CLS) erläutert. Im Vergleich zu den Darstellungen in den Figuren 11 und 12 ist die Figur 14 um die Darstellung der Mitteilungssegmente MS erweiter . Es beinhaltet sowohl die echolose wie auch die echobehaftete Übertragungsar . Die von der Anwendung AW eintreffende Mitteilung M wird entsprechend der Größe in einzelne Mitteilungssegmente MS zerlegt. Diese Segmente MS wer- den vom Transportprofil TP als einzelne Sendeaufträge behandelt. Damit wird jeder Sendeauftrag von diesem auch bestätigt (interne Sendebestätigung SB bzw. interne Weitergabebestätigung WB) . Da für die Anwendung die Zerlegung der Mitteilung M in Segmente MS transparent ist, sammelt das Funk-Message Handling System FMHS alle Segmentquittungen und quittiert anschließend die vollständige Mitteilung M gegenüber der Anwendung AW. Falls notwendig, kann eine Segmentnachforschung SN initiiert werden, falls auf der Empfangsseite aufgrund der Übertragung der Segment-Nummern und der Gesamtsegmente-Anzahl erkannt worden ist, daß die Mitteilung M nicht vollständig übertragen worden ist . Die Segmentnachforderung SN veranlaßt dann eine nochmalige Übertragung der nicht angekommenen Mit- teilungs-Segmente MS. Die gestrichelt in Fig. 14 eingezeichnete P2-Quittung ist optional.
Das in Figur 15 schematisch dargestellte Quittierungsverfahren für Verbindungsorientierte Übertragung (COS) über Draht unterscheidet sich etwas von der Übertragung mit Funk. Für Funk wird zweckmäßigerweise eine interne Quittierung defi- niert, da Quittungen von der Gegenseite, bedingt durch den
Funkrichtungswechsel, die Übertragungszeiten von Mitteilungen M erheblich erhöhen. Dieses interne Quittierungsverfahren, das Gegenstand der Erfindung ist, wird für COS bei Drahtübertragung nicht eingesetzt, da über Draht eine Quittung von der Gegenseite ohne erhebliche Erhöhung der Übertragungszeit möglich ist. Damit können die aus X.400 bekannten Quittungen Pl und P2 verwendet werden. Zusätzlich zu diesen an die Anwendung weitergereichten Quittungen Pl und P2 (eine Quittung für jede Mitteilung M und jeden Adressaten) werden auf der FMHS- Protokollebene Quittungen für jedes Mitteilungs-Segment MS ausgetauscht. Im Falle, daß die schon bestätigten Segmente MS auf der Empfangsseite verlorengehen, kann diese auch eine Segmentnachforderung SN initiieren.
Anhand von Figur 16 werden im folgenden die Funktionen eines Funk-Message Handling Systems erläutert, bei dem das Prinzip nach der Erfindung angewandt wird. Aufgabe eines solchen Systems ist der asynchrone Datenaustausch zwischen den Anwendungen auf verschiedenen lokalen Systemen. Die Sendeaufträge werden dazu von der Anwendung AW entgegengenommen und entsprechend verschiedener Kriterien (mehrere Adressaten, Prio- rität, Wiederholung usw.) bearbeitet und schließlich an das TransportSystem weitergereicht. Diese Grundfunktion wird in Figur 16 als „Sendeaufträge bearbeiten" bezeichnet.
Aus der Existenz der Sendefunktion folgt die Empfangsfunktion als zweite Grundfunktion, die analog dazu als „Empfangsaufträge bearbeiten" beschrieben wird. Sie nimmt die Aufträge vom Transportsystem an und reicht sie nach Bearbeitung (z. B. Aufsammeln aller Segmente einer Mitteilung) an die Anwendung weiter. Neben Mitteilungen werden damit auch Quittungen über- geben.
Es wird nun die Sendefunktion beschrieben. Die Aufgaben der Sendefunktion lassen sich in drei Unterfunktionen einteilen:
a) Aufbereitung der Mitteilungen und Quittungen, b) Bearbeitung der Sendewarteschlange, c) Bearbeitung der Managementaufträge. Diese Unterfunktionen umfassen wiederum folgende Aufgaben:
Zu a) Aufbereitung der Mitteilungen und Quittungen:
Flußkontrolle :
Wird ein Sendeauftrag an das Funk-Message Handling System gegeben, so wird im Anschluß daran festgestellt, ob ein (konfigurierbarer) maximaler Grenzwert von momentan in Bearbei- tung befindlichen Aufträgen erreicht ist. Dazu wird in zweckmäßiger Weise die Anzahl der Auftragssegmente (Mitteilungssegmente und Quittungen) berücksichtigt. Ist dies der Fall, so wird so lange kein Auftrag mehr angenommen, bis ein (ebenfalls konfigurierbarer) minimaler Grenzwert unterschritten wird. Die Anwendung erhält bei Auftragsübergabe an das Funk- Message Handling System im Überlastfall eine negative Bestätigung. Zusätzlich wird vom Funk-Message Handling System bei Erreichen einer der Grenzwerte eine entsprechende Management- information an die Anwendung gegeben.
Verwaltungsinformation anlegen:
Bei Auf ragseingang wird die für das Funk-Message Handling System notwendige Verwaltungsinformation erzeugt/angelegt und der Auftrag in die Funk-Message Handling Syste (FMHS) - Logging-Datei eingetragen.
Datenkompression:
Die Datenkompression der Nutzdaten wird durchgeführt, falls dies im Sendeauftrag spezifiziert ist.
Erzeugung der Sendesegmente:
Ein Sendeauftrag an das Transportsystem wird vom Funk-Message Handling System logisch als Segment abgelegt. Diese Segmente werden vom Funk-Message Handling System im wesentlichen in Abhängigkeit folgender Parameter erstellt: Maximale Segmentgröße, Anzahl der Empfänger, QOS (Broadcast, echolos, echobehaftet) . Generell enthält jedes Segment eine Segment-Kopfin- formation. Würde eine Mitteilung ein Segment ergeben, das größer als die maximale Segmentgröße für das Funk-Message Handling System ist, so wird diese Mitteilung ihrer Größe entsprechend in zwei oder mehrere Segmente zerlegt. Enthält eine Mitteilung mehrere Empfänger, so wird sie im Falle von QOS „echobehaftet" intern logisch in mehrere Mitteilungen zu jeweils nur einem Empfänger zerlegt. Dies ist notwendig, da die Mitteilung jeweils komplett zu jedem der Empfänger übertragen werden muß. Für jeden Empfänger wird eine separate Quittung erzeugt. Die Kopfinformation der Mitteilungen zu den einzelnen Empfängern unterscheidet sich dabei jedoch nicht. Im Fall „Broadcast" und „echolos* wird die Mitteilung an alle spezifizierten Empfänger zugleich gesendet. Eine interne Vervielfachung der Mitteilung entfällt daher.
Eintrag der Einzelaufträge in die Sendewarteschlange: Mit dem Eintrag in die Sendewarteschlange wird die Unterfunktion „Aufbereitung der Mitteilungen und Quittungen" abgeschlossen. Die Information in der Warteschlange enthält zu- sätzlich zur eindeutigen Bezeichnung des Sendesegments weitere interne Steuerinformationen.
Zu b) Bearbeitung der Sendewarteschlange:
Die in der Sendewarteschlange vorhandenen Einträge werden vom Funk-Message Handling System unter Berücksichtigung der Priorität abgearbeitet. Ein weiteres Kriterium ist die Sendefolge, die bezogen auf jeweils ein Funkgerät möglichst den Wechsel des Empfängers vermeiden soll, um die Übertragung nicht durch daraus resultierende längere Pausen zwischen den Segmenten zu belasten. Falls zwischenzeitlich ein Sendeauftrag mit höherer Priorität eintrifft, hat dieser jedoch Vorrang. Meldungen, die nicht erfolgreich quittiert wurden, verbleiben so lange in der Sendewarteschlange, bis eine spezifi- zierte maximale Verweilzeit (konfigurierbar) im Funk-Message Handling System verstrichen ist . Wiederholungen finden zwischen den normalen Sendeaufträgen statt, jedoch nicht vor Ab- lauf einer Wiederholzeitspanne (konfigurierbar) . Ein erneuter Sendeauftrag wird in CLS-Betriebsart dann an das Transportsystem gegeben, wenn ein erteilter Auftrag positiv oder negativ vom Transportsystem quittiert wurde. Für die Betriebsart COS wird vor dem Sendeauftrag an das Transportsystem das Bestehen der entsprechenden Transportverbindung geprüft . Falls diese nicht besteht, wird sie vom Funk-Message Handling System aufgebaut. Je nach Betriebsart kann die Verbindung für jeden Sendeauftrag jeweils auf- und abgebaut oder permanent beste- hen bleiben (konfigurierbar) . Sämtliche Sendeaufträge an das Transportsystem bzw. Quittierungen von diesem schlagen sich in einer Aktualisierung der internen Verwaltungsinformation nieder. Alle Quittierungen werden in die Funk-Message Handling System(FMHS) -Logging-Datei eingetragen.
Zu c) Bearbeitung von Managementauf rägen:
Folgende Managementaufträge können von der Anwendung ausgeführt werden: Suchen/Löschen einer Mitteilung aus der Sende- warteschlange, Funkstille ein/aus. Aktualisieren der Funk- Message Handling System-Betriebsparameter (nicht Adressen) , Information über Sendewarteschlangen für jede Priorität, Ausgabe von Fehlermeldungen. Alle Informationen werden an die Anwendung bzw. an das Network-Management weitergereicht.
Die Aufgaben der E pfangsfunktion lassen sich in zwei Unterfunktionen einteilen:
a) Meldungen analysieren, b) Mitteilung zusammenstellen.
Diese Unterfunktionen umfassen folgende Aufgaben:
Zu a) Meldungen analysieren:
Eine empfangene Meldung wird bezüglich ihres Typs untersucht Sie kann sowohl vom Typ „Mitteilung", als auch vom Typ „Quittung" sein. Dies kann anhand der Struktur des Meldungskopfs ermittelt werden. Interne Sendebestätigungen für Segmente werden in die Sendewarteschlange eingetragen. Dort wird geprüft, ob die Bestätigungen für alle Segmente vorliegen, um in diesem Fall eine Bestätigung für eine komplette Mitteilung an die Anwendung zu übergeben. Segmentbestätigungen von extern (COS) werden in die Sendewarteschlange ebenfalls eingetragen. Falls keine Pl-Quittung erwartet wird, dient diese Information zum Löschen der Verwaltungsinformation. Im ande- ren Fall erfolgt dies erst bei Eintreffen der Pl-Quittung. Die Pl- und P2-Quittung werden an die Anwendung weitergegeben. Alle Quittungen werden in die Funk-Message Handling System(FMHS) -Logging-Datei eingetragen.
Zu b) Mitteilung zusammenstellen:
Ebenso wie die Prüfung aller Segmentbestätigungen einer Mitteilung auf Vollständigkeit werden auch die empfangenen Segmente einer Mitteilung auf Vollständigkeit geprüft . Ist diese gegeben, so kann die Meldungskopfinformation entnommen und die Nutzdaten aus den einzelnen Segmenten können zusammengesetzt werden. Der Empfang des Segmentes wird ebenso wie die Weitergabe der kompletten Mitteilung in die Funk-Message Handling System(FMHS) -Logging-Datei eingetragen. Die Auswer- tung des Meldungskopfs zeigt, ob eine Datenkompression durchgeführt werden muß. Weiterhin wird festgestellt, ob eine Pl- Quittung zurückgesendet werden muß. Ist dies der Fall, so wird eine Pl-Quittung erstellt und in die Sendewarteschlange mit der Priorität der Mitteilung eingeordnet.
Im folgenden wird die Funktion der Kommunikationssteuerung erläutert .
Von der Anwendung erhält das Funk-Message Handling System Mitteilungen verschiedener Größe. Um eine sichere Übertragung einer Information zu erzielen, wird diese Information generell in kleinere Teileinheiten zerlegt, bevor sie physika- lisch übertragen wird. Damit muß im Fall von Übertragungsfehlem eine kleinere Informationsmenge und nicht die komplette Mitteilung wiederholt werden. Ist die Übertragungsstrecke für eine gewisse Zeit gestört, so wird die Übertragung der Daten auf der TransportSchicht abgebrochen. Um dennoch eine Mitteilung übertragen zu können, unternimmt das Funk-Message Handling System weitere Sendeversuche, die einen größeren Zeitrahmen abdecken. Damit wird die Wahrscheinlichkeit einer erfolgreichen Übertragung wesentlich gesteigert. Im Vergleich zu größeren Informationseinheiten schneiden kleinere Einheiten in bezug auf die Übertragungswahrscheinlichkeit unter Störeinfluß besser ab. Aus diesem Grund besitzt das Funk- Message Handling System die Möglichkeit, größere Mitteilungen in sogenannte Mitteilungssegmente zu zerlegen. Wiederholt werden müssen damit nur die noch nicht erfolgreich gesendeten Segmente. Damit sind sogenannte Wiederaufsetzpunkte zur Fortsetzung der Übertragung einer Mitteilung definiert. Da die optimale Größe dieser Mitteilungssegmente vom jeweiligen Einsatzfall abhängt, ist dieser Wert konfigurierbar. Berücksich- tigt werden muß dabei auch das Verfahren bzw. die Parametrie- rung des Transportsystems, um eine optimale Anpassung zu erzielen. Da ausschließlich vollständig empfangene Mitteilungen an die Anwendung weitergereicht werden, verfügt nur ein Segment der Mitteilung über die komplette Kopfinformation. In zweckmäßiger Weise ist dies das erste Segment. Alle folgenden Segmente müssen lediglich bezüglich ihrer Zugehörigkeit zu einer Mitteilung und ihrer Segment-Nummer identifiziert werden können. Die dazu notwendigen Parameter der Kopfinforma- tionen sind:
1. Gesamtanzahl der Segmente der Mitteilung,
2. laufende Segment-Nummer,
3. Funk-Message Handling System-ID und
4. Absender.
Allgemein betrachtet ist das Funk-Message Handling System eine Komponente eines Gesamtsystems. Es tauscht mit anderen Komponenten wie der Anwendung und dem Transportsystem Daten aus. Da jede Komponente über einen endlichen Datendurchsatz verfügt, der sich jedoch von Komponente zu Komponente unterscheidet, muß eine Regelung des Datenflusses erfolgen. Zur Anpassung an wechselnden Datendurchsatz verfügt das Funk- Message Handling System wie auch das TransportSystem über eine Auftragswarteschlange, in der bei kurzzeitig überhöhtem Eingang von Sendeaufträgen diese bis zur Bearbeitung zwischengespeichert werden können. Zur Steuerung des Datendurch- satzes wird deshalb der Füllgrad der Auftragswarteschlange herangezogen. In bezug auf die Anwendungsschnittstelle bedeutet dies, daß Mitteilungen niedriger Priorität nur in einem bestimmten Umfang entgegengenommen werden. Treffen nun Mitteilungen höherer Priorität ein, so können sie ohne Ein- schränkung entgegengenommen werden. Ein weiterer Vorteil entsteht durch die Minimierung der Verwaltungsinformation. Da die Übertragung von Mitteilungen im allgemeinen nur in einem bestimmten Zeitraum sinnvoll ist, läßt sich im Funk-Message Handling System eine maximale Verweilzeit der Mitteilungen einstellen. Würde ohne Flußkontrolle die Anzahl der an das Funk-Message Handling System übergebenen Mitteilungen kontinuierlich gesteigert, so würde zwangsläufig ein Zustand erreicht werden, in dem eine Mitteilung im angegebenen Zeitrahmen aufgrund des endlichen Durchsatzes des TransportSystems nicht mehr gesendet werden könnte. In diesem Fall würde ein Sendeauftrag, da er im spezifizierten Zeitrahmen nicht endgültig bearbeitet werden kann, nur die Verwaltungsinformation des Systems unnötig erhöhen und die Effizienz beeinträchtigen. Verfügt die Anwendung gleichzeitig über eine Möglich- keit, im Falle der Ablehnung von Sendeaufträgen durch das
Funk-Message Handling System diesen Systemzustand dem Nutzer anzuzeigen, so kann dieser in geeigneter Weise auch darauf reagieren.
Bevor das Funk-Message Handling System in den operationeilen Betriebszustand übergeht, müssen zunächst alle Konfigurationsparameter aus den entsprechenden Konfigurationsdateien ge- lesen werden. Falls keine Funk-Message Handling System(FMHS) - Logging-Datei vorhanden ist, wird eine neue angelegt. Somit besitzt die Applikation die Möglichkeit, vor jedem Start, falls gewünscht, eine neue Funk-Message Handling System- Logging-Datei anzulegen. Da das Funk-Message Handling System alle für den Bearbeitungsstand relevanten Parameter auf der Festplatte des Rechners ablegt, kann es aufgrund dieser Information ziemlich genau an derjenigen Stelle wiederaufsetzen, an der es abgebrochen wurde. Ist ein Neustart ohne Wie- deraufsetzen erforderlich, so kann die Applikation vor dem Funk-Message Handling System-Neustart alle Informationen im Arbeitsbereich des Funk-Message Handling Systems löschen.
Die Funk-Message Handling System-Mitteilung besteht aus der Kopfinformation und den Nutzdaten. Die Kopfinformation ist zur Minimierung der zu übertragenden Datenmenge binär-codiert bis auf die Angabe der Mitteilungs-ID. Der Aufbau der Funk- Message Handling System-Quittung entspricht weitgehend dem Aufbau der Mitteilung. Lediglich der Nutzdatenanteil ist nicht vorhanden. Da die binäre Kopfinformation unterschiedliche Parameter enthält, die identifiziert werden müssen, werden spezielle Kennzeichnungen verwendet. Um diese jedoch nicht für jeden Parameter angeben zu müssen, werden gemäß einer vorteilhaften Weiterbildung der Erfindung verschiedene Parameter entsprechend ihres Auftretens in der Kopfinformation zu sogenannten Datenfeldern zusammengefaßt . Dabei enthält nur jedes Datenfeld eine Kennzeichnung. Gleichzeitig wird sichergestellt, daß bis zum Auftreten des letzten möglichen Datenfeldes die Datenfeldkennzeichnung nicht über einen Para e- terwert in der Kopfinformation auftreten kann. Um die Datenmenge zu minimieren, besteht die Datenfeldkennzeichnung in zweckmäßiger Weise nur aus einem Byte.

Claims

Patentansprüche
1. System zur Anwenderunterstύtzung (Message Handling System, MHS) bei der Abwicklung von Informationsübertragungen in ei- nem Daten-Kommunikationssystem von einem Benutzer zu einem anderen Benutzer, insbesondere auch unter Verwendung von Funkübertragung, wobei die Anwendung auf den Diensten des MHS-Systems und das MHS-System wiederum auf den Diensten eines TransportSystems aufsetzt und letzteres direkt die Infor- mationsübertragungseinrichtungen ansteuert, welche die Informationen in ein für die jeweilige Übertragungsstrecke geeignetes Format umsetzen, so daß unter Übertragung von Protokollen die Anwendersendeaufträge automatisch bearbeitet und die vorhandenen Kommunikationsmittel selbsttätig gesteuert wer- den, dadurch gekennzeichnet, daß nur ein „peer-to- peer"-Protokoll ohne Richtungswechsel des Informationsflusses, jedoch voller Funktionalität vorgesehen ist, wobei anstelle einer vom empfangenden Benutzer rückgesendeten Quittung eine vom Transportsystem (TS) des die Information aus- sendenden Benutzers generierte interne Quittung (UI) zur Anwendung (AW) hin vorgesehen ist.
2. System nach Anspruch 1, dadurch gekennzeichnet, daß ein Sendeauftrag des Benutzers (Anwendung AW) an sein Transportsystem (TS) vom MHS-System logisch als ein Segment oder mehrere Mitteilungs-Segmente (MS) abgelegt werden, die jeweils eine Segment-Kopfinformation enthalten, daß die Segment-Nummern und die Gesamtsegmente-Anzahl übertragen werden, so daß auf seiten des empfangenden Benutzers die Vollständig- keit einer Mitteilung (M) erkennbar ist und sich bei Feststellung einer unvollständigen Mitteilungsübertragung mittels einer Segmen -Nachforderung (SN) eine nochmalige Übertragung der nicht angekommenden Mitteilungs-Segmente (MS) veranlassen läßt (WiederaufSetzungsfunktion) .
3 . System nach einem der vorhergehenden Ansprüche , d a d u r c h g e k e n n z e i c h n e t , daß das „peer-to-peer" -Protokoll so aufgebaut ist, daß zusätzlich zu den mit jedem Sendevorgang ausgetauschten „peer-to-peer"-Nutzdaten vom aussendenden Benutzer eine minimierte Kopfinformation ausgesendet wird, die hinsichtlich Dataset-Bezeichner, Adreßinformationen (Empfänger, Absender) , Segment-Nummer und Segmente-Anzahl , Erstejlzeit , Klassifizierung, Priorität, Datenkompression, Quittierungsverfahren, Adreßtyp binärcodiert ist, wobei anstelle von Feld-Bezeichnern Dataset-Bezeichner verwendet werden, die mehrere Felder umfassen.
4. System nach einem der vorhergehenden Ansprüche, dad rch gekennzeichnet , daß das Daten-Kommunikationssystem auf ein Funksystem optimiert ist, bei dem die Benutzer Teilnehmer in einem Funkkreis sind.
5. System nach Anspruch 4, dadurch gekennzeichnet, daß zusätzlich zu den Benutzeradressen eine MHS-Broadcast (Rundsendung „an alle") -Adresse definiert ist, die grundsätzlich dann eingetragen wird, wenn von einem Benutzer eine Mit- teilung „an alle" gesendet werden soll.
6. System nach Anspruch 5, dadurch gekennzeichnet, daß die Transportadresse frei konfigurierbar ist.
7. System nach einem der vorhergehenden Ansprüche, gekennzeichnet durch die Vorgabe einer „Funkstille"- Funktion für das MHS-System, bei der lediglich Mitteilungen empfangen, aber nicht gesendet werden können.
8. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß optional bei bestimmten Betriebsarten zusätzlich Quittungen vom empfangenden Benutzer zum sendenden Benutzer hin abgegeben werden.
EP97936607A 1996-08-09 1997-08-08 System zur anwenderunterstützung (message handling system, mhs) bei der abwicklung von informationsübertragungen in einem daten-kommunikationssystem Withdrawn EP0968595A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19632258A DE19632258C1 (de) 1996-08-09 1996-08-09 System zur Anwenderunterstützung (Message Handling System, MHS) bei der Abwicklung von Informationsübertragungen in einem Daten-Kommunikationssystem
DE19632258 1996-08-09
PCT/DE1997/001688 WO1998007260A1 (de) 1996-08-09 1997-08-08 System zur anwenderunterstützung (message handling system, mhs) bei der abwicklung von informationsübertragungen in einem daten-kommunikationssystem

Publications (1)

Publication Number Publication Date
EP0968595A1 true EP0968595A1 (de) 2000-01-05

Family

ID=7802287

Family Applications (1)

Application Number Title Priority Date Filing Date
EP97936607A Withdrawn EP0968595A1 (de) 1996-08-09 1997-08-08 System zur anwenderunterstützung (message handling system, mhs) bei der abwicklung von informationsübertragungen in einem daten-kommunikationssystem

Country Status (4)

Country Link
EP (1) EP0968595A1 (de)
DE (1) DE19632258C1 (de)
NO (1) NO990576L (de)
WO (1) WO1998007260A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6877023B1 (en) 2000-01-28 2005-04-05 Softwired, Inc. Messaging system for delivering data in the form of portable message formats between message clients
US6721779B1 (en) 2000-07-07 2004-04-13 Softwired Ag Messaging proxy system
US7489781B2 (en) 2004-10-29 2009-02-10 Research In Motion Limited Secure peer-to-peer messaging invitation architecture

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4908828A (en) * 1987-12-29 1990-03-13 Indesys, Inc. Method for error free message reception
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9807260A1 *

Also Published As

Publication number Publication date
NO990576L (no) 1999-03-24
DE19632258C1 (de) 1997-12-11
NO990576D0 (no) 1999-02-08
WO1998007260A1 (de) 1998-02-19

Similar Documents

Publication Publication Date Title
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE69434330T2 (de) Übertragungsvorrichtgung und verfahren
DE60023019T2 (de) Verfahren und system zur ablösung oder regeneration von quittierungspaketen in adsl kommunikationen
DE60029221T2 (de) Begrenztes automatisches wiederholungsaufforderungsprotokoll für rahmenbasierte kommunikationskanäle
DE60031263T2 (de) Umhüllungsverfahren für protokolldateneinheiten
DE60203221T2 (de) Verwendung von mehreren virtuellen Kanälen in Netzwerkgeräten
DE69531410T2 (de) Mehrrechnerumgebungen
DE60113906T2 (de) Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression
DE60300354T2 (de) Methode zur Rekonstruktion paketisierter Nachrichten, die über ein oder mehrere Netzwerke verschickt wurden
DE60109959T2 (de) Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen
DE602004010851T2 (de) Verfahren und einrichtungen zur duplikatpaketidentifikation während eines handover
DE19730159B4 (de) Kommunikationsverfahren und System
WO1999035797A1 (de) Verfahren zum datentransport sowie rechnernetzwerk zur durchführung des verfahrens
DE60133175T2 (de) Kommunikationsnetz
DE60108324T2 (de) System und Verfahren zur Erhöhung von Nachrichtendurchsatz in einem Funknetzwerk
DE60126941T2 (de) System und verfahren zur durchführung von lokalen basisstationen
DE60316419T2 (de) Serialisierung von eine Verteiltenapplikation einer Router
DE60208990T2 (de) Verfahren zur Unterscheidung von Teilnehmer eines Kommunikationssystems, Kommunikationssystem und Kommunikationsgerät
EP3211838A1 (de) Redundant betreibbares industrielles kommunikationssystem, verfahren zu dessen betrieb und funk-transceiver-station
DE10296700T5 (de) Flusssteuerungssystem zur Verringerung der Speicherpufferanforderungen und zur Herstellung einer Prioritätsbedienung zwischen Netzen
DE60133067T2 (de) Verfahren und Vorrichtung zum Wiederzusammensetzen von Paketen in einer Vermittlungsstelle
EP0831620A2 (de) Lokales Netzwerk mit zur Funkübertragung vorgesehenen Terminals
DE60118673T2 (de) System und Methode zur Bewahrung der Bandbreite bei der Übertragung von Nachrichtenpaketen
EP0957613A1 (de) Verfahren und Vorrichtung zur Erhöhung eines Datendurchsatzes
DE60036121T2 (de) Hochgeschwindigkeitsverbindung für eingebettete Systeme in einem Rechnernetzwerk

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990305

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT CH FR GB IT LI NL SE

17Q First examination report despatched

Effective date: 20010807

RIC1 Information provided on ipc code assigned before grant

Free format text: 7H 04L 12/58 A, 7H 04L 29/08 B

RTI1 Title (correction)

Free format text: APPLICATION SUPPORT SYSTEM TO BE USED DURING THE INFORMATION TRANSMISSION IN A DATA COMMUNICATION SYSTEM

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

RIC1 Information provided on ipc code assigned before grant

Ipc: 7H 04L 29/08 B

Ipc: 7H 04L 12/58 A

RTI1 Title (correction)

Free format text: APPLICATION SUPPORT SYSTEM TO BE USED DURING THE INFORMATION TRANSMISSION IN A DATA COMMUNICATION SYSTEM

RIN1 Information on inventor provided before grant (corrected)

Inventor name: OSSIANDER, GERHARD

Inventor name: KRATZER, ANDREAS

Inventor name: KAMPHAUSEN, WOLFGANG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030604