Search

EP-4489379-B1 - TRANSMITTING AND RECEIVING DATA VIA A SERIAL, ASYNCHRONOUS INTERFACE

EP4489379B1EP 4489379 B1EP4489379 B1EP 4489379B1EP-4489379-B1

Inventors

  • ANDERBERG, ANDREAS
  • REHN, HENNING

Dates

Publication Date
20260506
Application Date
20230705

Claims (15)

  1. A method for transmitting data via a serial, asynchronous interface, the method comprising the following steps: operating (S10) a device in a text-based receiving protocol mode, receiving (S12), by the device while operating in the text-based receiving protocol mode, via the interface, a request message (Rq) comprising a binary header component and a length indication, entering (S13), by the device, into a binary receiving protocol mode upon receipt of the request message, receiving (S14), by the device while operating in the binary receiving protocol mode, an amount of binary data (D), the amount being specified by the length indication of the request message, exiting (S15), by the device, the binary receiving protocol mode.
  2. The method according to claim 1, wherein operating (S10) the device in the text-based receiving protocol mode comprises initializing (S11) operation in the binary receiving protocol mode.
  3. The method according to claim 2, wherein initializing (S11) operation in the binary receiving protocol mode comprises receiving, by the device, at least one command message (Cd1a) comprising a header and a command component, and wherein the command message complies with the AT command set.
  4. The method according to any of claims 1 to 3, further comprising sending (S16), by the device, while receiving the amount of binary data (D), a notification message (Nf) comprising a notification component defining a maximum amount of data which the device is able to receive, and receiving, by the device, another amount of binary data while operating in the binary receiving protocol mode, this other amount of binary data being specified by the notification component of the notification message.
  5. The method according to claim 4, wherein the notification message (Nf) additionally comprises a confirmation information confirming successful receipt of the command message and the request message.
  6. The method according to claim 4 or 5, further comprising directly after the receiving, by the device while operating in the binary receiving protocol mode, the another amount of binary data, entering, by the device, into the text-based receiving protocol mode, and receiving, by the device while operating in the text-based receiving protocol mode, another command message (Cd1b) comprising a header component and a command component.
  7. A method for receiving data via a serial, asynchronous interface, the method comprising the following steps: operating (S20) a device in a text-based sending protocol mode, sending (S22), by the device while operating in the text-based sending protocol mode, via the interface, a request message (Rq) comprising a binary header component and a length indication, entering (S23), by the device, into a binary sending protocol mode, sending (S24), by the device, while operating in the binary sending protocol mode, an amount of binary data (D), the amount being specified by the length indication of the request message, exiting, by the device, the binary sending protocol mode.
  8. The method according to claim 7, wherein operating the device in the text-based sending protocol mode comprises initializing (S21) operation in the binary sending protocol mode.
  9. The method according to claim 8, wherein initializing operation in the binary sending protocol mode comprises receiving, by the device, at least one command message (Cd2a) comprising a header component, a command component and a first length indication, wherein the command message complies with the AT command set, and the command component triggers the subsequent sending of the request message, and sending, by the device, a confirmation message (Cf1) confirming receipt of the command message and comprising a second length indication.
  10. The method according to any of claims 7 to 9, further comprising while sending the amount of binary data by the device, receiving, by the device, another command message (Cd2b) comprising a header component, a command component and another length indication, continuing with sending, by the device in the binary sending protocol mode binary data according to the another length indication of the another command message.
  11. The method according to claim 8, wherein initializing operation in the binary sending protocol mode comprises sending, by the device, a trigger message (Tr1) comprising an indication of an amount of available binary data.
  12. The method according to any of claims 1 to 11, wherein the binary header component of the request message (Rq) comprises a pre-defined character.
  13. A device, comprising means configured to perform the method according to any of claims 1 to 6, and/or means configured to perform the method according to any of claims 7 to 12, and the serial, asynchronous interface.
  14. The device according to claim 13, wherein the device is implemented as an integrated module further comprising hardware and software components (12) for realizing a communication functionality, and wherein the communication functionality is configured for control via the serial, asynchronous interface.
  15. System comprising a device (10) according to claim 13 or 14 and a host apparatus (20) comprising a serial, asynchronous interface, which is coupled to the serial, asynchronous interface of the device, wherein the host apparatus is configured for communication using the device via the serial, asynchronous interface.

Description

Technical field The present disclosure relates to the field of communication, especially to exchange of data, i.e. sending and receiving data via an interface. Specifically, the disclosure is directed to a method for transmitting data via a serial, asynchronous interface, a method for receiving data via a serial, asynchronous interface, a device and a system. Background In the field of exchange of data between different devices communication protocols are used for enabling involved devices to communicate with each other. Usually interfaces are defined which provide access to such protocols, thereby freeing involved devices from the burden of knowing all of the specifics defined in the protocol. A well-known example of such an interface is the so-called socket interface, which provides access to a Transmission Control Protocol, TCP, Internet Protocol, IP, User Datagram Protocol, UDP, protocol implementation, also referred to as a TCP/IP or UDP/IP protocol stack. An interface is employed within a device for exchanging data between different modules or entities, like protocol stacks or radio frequency transmitter-receiver modules. An interface may be realized as a serial or a parallel interface and may be operated synchronously or asynchronously. This description focusses on interfaces which exchange data in a serial, asynchronous way, i.e. without using a clock signal that is shared between a participating sender and receiver. Furthermore, an interface may be implemented as a text-based interface, which is controlled by readable text or strings. Another type of interface is realized as a binary interface, accepting and providing binary data. This description is directed to text-based types of interfaces. A well-known and widely implemented text-based, asynchronous, serial interface is the AT command set, sometimes also referred to as the Hayes AT command set. This AT command set is renowned as a de-facto standard in communications. The AT command set used nowadays originates from the Hayes AT command set or modem attention command set, which had been developed by Hayes for telephone modems. State of the art implementations of the AT command set interface are also used for providing access to TCP/UDP/IP sockets. Unfortunately, known asynchronous, serial interfaces often suffer from low throughput resulting from wait states caused by inevitable synchronization between sending and receiving parties, for example a host and a module, in the course of data exchange. In detail, a host, e.g. an entity using communication functionality, and a module, e.g. an entity providing said communication functionality, should be synchronized before transmitting data. For this, receipt of commands and/or data is actively confirmed. In detail, it may be necessary to indicate to the host or module when data have been received and further data can be transmitted by the module or host. If either host or module runs out of memory, the transmission has to be interrupted. An established solution to these problems is, for example, the use of flow-control mechanisms. Specifically, a host may issue a command asking the module how much data a module can accept, which, however, introduces more wait states. Or a host may send data without knowing the amount of data a module can accept, which may lead to a complete pause of the whole communication channel if the module runs out of memory, or in the worst case may lead to loss of data and imply a retransmission. In any case, the resulting throughput across the interface is unsatisfactorily low, especially when compared to data rates and corresponding throughput realized by communication technologies like WiFi or Ethernet, which may be controlled via such an interface. The interface may even end up as the bottleneck in this type of communication. "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) (3GPP TS 27.005 version 5.0.0 Release 5)", ETSI TS 125 212 V6.6.0, XP002282827 discloses three interface protocols for control of SMS functions within a GSM/UMTS mobile telephone from a remote terminal via an asynchronous interface. Those protocols include a binary protocol ("Block Mode"), a character-based interfaced based on "AT" commands ("Text Mode") and another character-based interface with hex-encoded binary transfer of message blocks ("PDU Mode"). In text mode, message data parameters are used, one of which is the parameter <length>, an integer type value indicating in the text mode (+CMGF=1) the length of the message body <data> > (or <cdata>) in characters; or in PDU mode (+CMGF=0), the length of the actual TP data unit in octets. "3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS) (Release 4)", 3GPP STANDA