DE102016124007A1 - Method for transmitting a message - Google Patents

Abstract

The invention, which relates to a method for transmitting a message, has the object of specifying a method for transmitting a message, with which a local reception of location-based dynamic information is achieved by means of a mobile terminal. In addition, the costs for the user are lowered, the privacy protected, relieves existing mobile networks and a comfort and time savings for the user. In the method according to the invention for transmitting a message, in which a transmission of the message (1) from a transmitter to a receiver by means of a Bluetooth low energy method (BLE), wherein the message (1) before sending on several segments (2) where each segment (2) has a header (3) preceding the segment (2) and each header (3) has at least one indication of a segment ID (5), when the divided message (1) is assembled, the Determines the order of segments (2).

Description

The invention relates to a method for transmitting a message, in which a transmission of the message from a transmitter to a receiver by means of a Bluetooth low energy method (BLE), wherein the message is divided into several segments before sending and wherein each segment one the segment prefixed header.

This document describes a method for the transmission of messages or so-called short messages by means of Bluetooth low energy (BLE) using so-called "advertising packets" in the broadcasting mode.

The term "short message" used in this description is rather general and indicates that the information to be transmitted should be of limited length, similar to a short message service (SMS).

The type of news or information that makes the most sense for the process is location-based, dynamic information. Location-based, dynamic information is characterized by being relevant only to a particular location or a limited perimeter and for a limited time. Such information can be recognized, for example, by the fact that they are transmitted at the location of their meaning by optical display or also via acoustic announcement. However, this does not mean that location-based, dynamic information is basically bound to existing optical or acoustic transmission. Some examples of such location-based, dynamic information are described below.

In the field of public passenger transport, this location-based information, for example, planned and / or actual departure and / or arrival times, line numbers, a direction or a destination, a compartment or space utilization in a means of transport, a planned or held train entrance, a current state of clearance ("No more boarding"), an exit side of a means of transport, the next stops, connection options, connection security, possibly expected traffic delays, scrolling text and more.

In an airport, such location-related information may be, for example, information about a departure schedule, a boarding status, an assignment of the gates to the flight numbers, an arrival schedule with planned and actual times.

In the area of trade, special offers, a voucher / voucher, a menu, price indications (e.g., petrol station), health charts (e.g., stock exchange), and other information may be provided.

For users of the public traffic area, for example, traffic jam messages, detour recommendations or the availability of parking spaces can be provided.

Concerning local planned events, interested parties can be provided with information about schedules, a program schedule as well as a current occupancy or room occupancy. When participating in an event, information about the current event as well as about the speakers or artists may be useful.

At sporting events, information about a team line-up, matches of parallel games, split times and competition results can be provided.

In addition, for example, information about currently called numbers or tokens of a waiting list, with or without information about the route to reach the counter or room, may be provided in public authority waiting rooms. Also, data on the current weather, including a temperature, a wind direction or wind force and an air pressure may be of interest.

For the determination and evaluation of location-relevant information, mobile terminals such as smartphones, laptops and tablets with corresponding applications are nowadays available. These enable a user to answer questions such as "Where is the closest restaurant to my location?", "Where is the nearest stop?", "How do I get there?", "When does the bus you want to take from there?" Etc. to get answers.

Requirements for this service are usually a use of a location service such as the global positioning system GPS or other such systems by the user's smartphone and a data connection to the Internet. The permanent activation of location services is perceived by many users of mobile devices as problematic in terms of their privacy. In addition, permanently activated location services lead to shorter battery life due to your increased energy requirements. To prevent both problems, users can locate services optionally only activate when they are actually needed.

The activation and deactivation of location services is associated with various hurdles and inconveniences, depending on the operating system and settings. In some operating systems, such as the Android 4.4.2 operating system, the activation and deactivation of location services via a quick menu can be done quickly and easily. For this purpose, only a so-called stroking and a typing or clicking movement are required.

On the other hand, with iOS 9.1 there are five steps to activate location services, consisting of a click action, a swipe, and three more clicks. If you want to disable location services, the iOS 9.1 OS adds an extra confirmation click. If other settings have been changed in the meantime, and if the path to deactivate leads from the start screen via the settings menu, iOS 9.1 requires six steps to deactivate it.

If the positioning system GPS has not been activated for a long time and no alternative location information is available, such as information provided by the GSM base station and / or WLAN access points, or disabled, then it may take up to several minutes to complete the current one Location was determined with sufficient accuracy.

A mobile data connection to the Internet is a reality for most users today. However, this is often limited to a specific monthly data volume, which is usually fixed in the mobile phone contract. In principle, however, the possibility of a mobile data connection as a prerequisite for these and other applications is unproblematic today.

The limitation to a limited volume of data gives the user the feeling at the beginning of a month that they do not have to worry about the data connections at first. If the volume is used up prematurely, the user has to make do with a greatly reduced data rate or bear the costs of another data volume. If possible, the user could log in to protect the mobile data volume on public Wi-Fi access points to establish a data connection to the Internet. However, this is often associated with a time-consuming selection of access points, acceptance of terms and conditions, possibly entry of access codes and similar inconvenient hurdles.

In this respect, it is desirable for users to be provided with applications which already offer an added value of information without a mobile data connection.

It would also be advantageous if the user knows that the use of a particular application does not involve any risk in terms of data volume consumption or other costs. A high acceptance and widespread use of such applications would be the result.

In a case of data roaming in which the user requires a mobile data connection abroad, the cost factor plays an even more crucial role. This can quickly result in unexpectedly high costs. This applies in particular if data is transferred unnoticed in the background, ie without direct knowledge or consent of a user. Careful users therefore disable data roaming before traveling abroad. Thus, no mobile data connection to the Internet for the transmission of data corresponding services is available.

Especially on trips abroad, however, the need for spatial orientation due to lack of local knowledge is particularly high. Mobile devices could provide a valuable help in this case, if they could receive locally transmitted, location-relevant information and display or further processed without being dependent on an Internet connection.

In addition, suitably equipped applications could equally cover the translation function, for example, translate in public transport, names of streets and squares or traffic lines, especially if it is unreadable for the traveler writing (for example, Cyrillic, Chinese, Japanese, Arabic etc.).

Such applications are not only of interest when traveling abroad. In locations such as train stations, airfields and similar, where foreign travelers face the same orientation problems, such support through location-based dynamic information is beneficial.

Another aspect, regardless of whether you are living abroad or abroad, is that Wi-Fi or mobile data connections to transfer data over the Internet always provide a point of contact for user monitoring. From the point of view of protecting the privacy of users, it would also be desirable, if in certain respects Applications Alternative options exist in which an Internet connection can be dispensed with.

In cases where a large number of users retrieve identical location-based, dynamic information via a mobile data connection because of their common location or context, for example at a major event, sports event, airport terminal or the like, high burdens on the existing one arise mobile network. One or a few base stations have to handle the high number of data requests. The limited bandwidth of the mobile data connection leads to reduced data throughput and waiting times for the individual user. The fact that the same information is requested by many users at the same time also represents an inefficient load on the mobile network due to high data redundancy. This situation could be avoided if the requested information is transmitted locally locally by radio, for each by means of a mobile Endgerät as a smartphone receivable, would be sent out. This would be accompanied by a reduction in the mobile network.

The transmission of short messages via Bluetooth Low Energy (BLE) Broadcasting could help here. However, due to the comparatively low data rate of the BLE broadcasting method compared to common mobile data connections, it would still be necessary to investigate under which framework conditions (for example type of information) and from which quantitative boundary conditions the advantages of the broadcasting method would come into play.

For several years, a wide variety of applications for mobile devices have enabled traffic information and travel planning in the public transport sector. As part of the expansion and modernization of computational operations control systems (RBL) local transport companies so-called "data turntables" have emerged, the timetables and real-time information (eg location) of vehicles (eg bus, tram, train, subway) at a central location and bundle over the Internet provide. This in turn allows the display of real-time information (eg departure / delays vs. planned departure, connection security, traffic obstruction) both on mobile devices (smartphones) with (mobile) Internet connection, as well as on passenger information displays at stops and in means of transport (also mobile Internet access required ). The increasing online availability of real-time data of other means of transport, e.g. Car sharing, rental bike or taxi, led to the trend of multimodal route planning, so a travel planning from A to B, in which various means of transport are used. The dynamics of this trend will be shown.

Applications for rice planning from A to B are quite helpful for irregularly used traffic connections and for initially unknown travel routes. In addition, a mobile Internet connection is necessary in order to be able to receive possible route updates, for example because of delays, missed connections etc., on the way.

With regular use of the same traffic connections, e.g. as a commuter, transfer routes and connection options are already known. It is unlikely that a commuter will ask for his or her identical and complete travel planning on a smartphone every day, spending valuable time on the operation of the application each time, knowing where the next stop is and how to reach it. Rather, a commuter would be interested in getting a stop, the planned, or better yet to get the actual departure time without much effort. This is made possible today either by notice schedules or optical departure displays. In particular, the range of optical scoreboards has been significantly expanded in the last 10 to 15 years, especially in the urban area.

For example, in the entrance area of an airport, there is often a large scoreboard to display scheduled departures. Usually these include: departure time, flight number, destination, baggage claim counter and status information. The first challenge for the passenger is finding his flight in a long list. With the help of reference information such as the planned departure time, the destination or even a flight number, the passenger determines the correct line to subsequently identify status information and baggage drop-off for his flight.

In the waiting area are also information displays. They indicate the passenger's important information such as a gate number or whether the gate is already open or closed.

• 1. Identifizierung (Filterung) der korrekten Zeile anhand von Referenzinformationen (Zeit/Ziel/Flugnummer)
• 2. Ablesen von Status und Gate
• 3. Prozedur bestehend aus 1. und 2. muss regelmäßig wiederholt werden („Polling“), um eine Änderung seines Flugstatus zu erkennen und darauf reagieren zu können.

The passenger is required as follows:

• 1. Identification (filtering) of the correct line based on reference information (time / destination / flight number)
• 2. Reading status and gate
• 3. Procedures consisting of 1st and 2nd must be repeated regularly ("polling") in order to be able to recognize a change in their flight status and be able to react to it.

To make matters worse in some cases added a small font size and the fact that the absolute line of your own flight according to flights handled can change dynamically.

During the stay in the waiting area, which is typically in a range between 30 and 90 minutes, the regular query duty is a stress factor for the passenger dar. It makes you feel uncomfortable, you could miss the flight, if you do the polling procedure too rarely. This is reflected in the fact that seats with a comfortable view of an information display are always filled first. The fear of missing status changes in his flight and thus getting into a stress situation affects the willingness to pay of waiting passengers.

The broadcast mode advertising described in the Bluetooth 4.0 specification is designed to provide information e.g. via the sending device, its services, name, etc., without receiving any feedback from the recipient. However, an advertising package does not necessarily have to contain such information. The specification also defines the use of manufacturer-specific data (AD-Type = "manufacturer-specific", 0xFF) within the advertising packets, which are also used in this method.

An advertising package consists of a maximum of 31 bytes or octets. Within an advertising package, several advertising data structures ("AD structures") line up. The first octet of an AD structure specifies the number of subsequent octets of the same AD structure without counting itself. The second octet of an AD structure describes the AD type. The definition of the AD type can be found at www.bluetooth.org → Specification → Assigned Numbers → Generic Access Profile. The remaining octets of an AD structure are the AD data. The interpretation of the AD data is possible via the AD types specified by BT-SIG.

The AD-Type 0xFF "Manufacturer Specific Data" (manufacturer-specific) is a special feature. This type is followed by two octets, which identify the manufacturer. Assigned "Company Identifiers" can be consulted at: www.bluetooth.org → Specification → Assigned Numbers → Company Identifiers. The meaning of the AD data of a Manufacturer Specific AD structure should be defined by the respective manufacturer. The method described below relates to such manufacturer-specific AD data.

The problem of BT4.0 Advertising / Broadcasting to use for short messages is the limited user data length of 31 bytes per raw advertising packet. Taking into account the minimum information for the BT specification as well as a "manufacturer specific header", 24 bytes remain for the payload data to be transmitted. This is considered insufficient for short messages.

Bluetooth low energy beacons (BLE beacons), also known as signal beacons, already use the Advertising mode today. Typically, BLE beacons are used in Broadcasting mode, i. without the possibility of establishing a connection from a device to the device emitting the beacon signal. BLE beacons send a long, unique code (UUID) regularly without this UUID changing, that is static. When a mobile device, such as a smartphone, enters the coverage area of a beacon, the mobile device receives the UUID. If an application (app) running on the mobile device recognizes this UUID, then specific actions within the application can be started and / or conclusions about the location of the user can be derived. Location information derived from the beacon signal may in turn be used as the basis for location-related information to be displayed on the mobile device or for other data processing.

The prerequisite is that the application can assign the received UUID with the aid of a database to a location or a facility such as a shop, restaurant, venue, station, means of transport, etc. This database can either be stored in the application, or it can be accessed online via the Internet.

This means that BLE beacons only provide reference information, but not the actual information that provides the user with real added value.

In order to obtain the actual value-added information, an application is required which either completely contains the database itself, accesses a central database via the Internet connection, or supplements or updates the database held in the mobile device under certain boundary conditions. Such boundary conditions may be, for example, the presence of an Internet connection or the current or future expected whereabouts.

The greater the dynamic nature of the bidding information, that is the frequency of occurrence of the information and its Changes or changes, the more important an existing Internet connection of the mobile device in connection with received BLE Beaconsignalen.

An example of an action within an app is the automatic display of restaurant menus on the user's smartphone as soon as it comes near the restaurant. Likewise, advertisements and coupons can be displayed as soon as the user comes close to the relevant store. Even within a store, several appropriately positioned BLE beacons, department-specific special offers or product information can be displayed on the smartphone.

In contrast to static BLE beacons, which continuously send out their constant UUID, there are also applications which send manufacturer-specific information via BLE Advertising, the content of which changes according to circumstances. Examples include sensors for physical quantities such as temperature, pressure, brightness, etc.

There is also a known public transport application that uses BLE Advertising to indicate the nearest bus stop. The transmitter is installed in the bus and constantly sends a constant, coded advertising packet, which is assigned to the next station. As soon as the next stop is announced on the passenger information display and / or by an acoustic announcement, the content of the continuously repeated advertising packets (dynamic information) also changes. The corresponding smartphone application can receive and decode the coded advertising packets. Accordingly, the next stop is displayed in sync with the passenger information display and acoustic announcement in addition to the smartphone of the user. As an additional function, the application allows to send the stop request to the driver via button. This is equivalent to pressing a stop request button installed in the bus.

At the BLE level, a connection between the smartphone and the BLE transmitter is set up for a short time. It follows that the used advertising packets have set the appropriate flag, which allows a connection. In this case, there is no pure broadcasting. Since the BLE radio waves propagate not only in the bus, but also outside, there is the possibility to trigger a stop request from outside, for example, by waiting at the stop passengers. As range, about 30 to 50 meters are observed.

A characteristic of the BLE advertising mode, which comes to the fore particularly with a dynamic information content, is a lack of authentication. In principle, it is easily possible for an attacker to simply send previously received advertising packets themselves ("replay attack"). On the other hand, various measures can be taken, e.g. various checksums, keys stored in the sensor or also the plausibility check of the reception location of beacon signals. For the latter, the location services of the mobile device would have to be activated. However, this is a disadvantage for the privacy of the user.

Authentication using checksums and / or stored, constant keys means that they are only secure until they have been decrypted or cracked. In contrast, dynamic change of keys would help at regular intervals. This, in turn, would require a secure channel which is encrypted and authenticated on both sides, from the location of the key generation to the sensor, which at least temporarily would have to be available for this purpose.

BT-SIG's typical use case calls for a connection between the sensor (peripheral role) and the mobile device (central role) to transmit dynamic data. Once a connection has been established, the Bluetooth specification provides appropriate security measures for authentication, encryption, etc., but not for the connectionless Advertising / Broadcasting mode.

The extent to which authentication measures in BLE Advertising with dynamic information are implemented today is difficult to assess, since, if these measures exist, they are mostly proprietary solutions. It stands to reason that the limited capacity of advertising packets (up to 31 bytes), in which both protocol information, sensor data or dynamic advertising information and authentication data would have to be accommodated, represents a hurdle for the authentication.

Common methods for ensuring authenticity and integrity initially form a checksum of the message, such a check sum also being referred to as a "hash". Subsequently, these methods sign the checksum using a private key and finally append the result, ie the signature, to the message. For example, the Standard SHA256 used as a hash function, this would require 256 bits = 32 bytes of capacity in addition to the actual message. This capacity is in a single BLE Advertising Packet (up to 31 bytes [raw] or 24 bytes [manufacturer-specific]) not available.

The known prior art has several disadvantages, which are described below.

In many cases, a mobile data connection is almost indispensable for determining and displaying location-related information. The costs thus incurred are not negligible, especially in the case of data roaming, in which a mobile network subscriber is active in a foreign network.

A further disadvantage is that the data transmitted via the Internet is fundamentally susceptible to surveillance, which contradicts the need for privacy.

Location tracking requires additional location services such as GPS (Global Positioning System). It would be desirable if a location as well as an Internet connection for the process are not needed. Such location-based information could be received anonymously directly by the actual on-site presence.

The determination and display of location-related, dynamic information takes place indirectly via primary reference information (location determination / BLE Beacon). The secondary information containing the added value is retrieved and displayed via an Internet connection. For such value-added information of small data size, it would be desirable to transmit from a local-site transmitter with limited range directly to the receiving device. In this way, the efficiency of the process could be increased and independence of location services and mobile Internet connections could be achieved. In addition, the mobile network could be relieved.

The object of the invention is now to provide a method for transmitting a message, with which a local reception of location-based dynamic information is achieved by means of a mobile terminal. In addition, the costs for the user are lowered, the privacy protected, relieves existing mobile networks and a comfort and time savings for the user.

The object is achieved by a method having the features according to claim 1 of the independent claims. Further developments are specified in the dependent claims 2 to 12.

The use of Bluetooth low energy (BLE) advertising data packets for the connectionless transmission of location-related, dynamic information or so-called short messages, appears due to the limited to 24 bytes payload length, as so-called "manufacturer specific data" initially makes little sense.

The inventive method provides to divide a message to be transmitted in several segments and to transfer. For this purpose, each segment is provided with specific header information which enables the receiver to uniquely identify a segment and determine when a message, ie all segments belonging to a message, have been completely received. Based on this specific header information, it is possible to reproduce the original message in the receiver. Since the transmitter receives no feedback from the receivers about the receipt of segments and their completeness, the transmission of the segments is repeated continuously according to a specific pattern.

The essential approach of the present invention thus consists in a division of a message into several segments corresponding to the maximum available size of about 19 to 21 bytes per segment. Furthermore, adding a segment header or protocol and continuously repeating the transmission of the segments is done according to a specific pattern to ensure reception of the segments at the receivers.

The transmission of short messages, in particular location-based, dynamic information, from a BLE transmitter directly to mobile terminals in a local area offers a number of advantages over the prior art.

For the user, a cost reduction through the independence of mobile data connection can be achieved.

The privacy of the user is improved. This is possible through the use of "privacy by design" in BLE broadcast mode, since in this mode of operation there is no possibility to establish a connection between the transmitter and the receiver. Thus, the reception of messages by the transmitter technically can not be determined.

The method works completely independently of location services such as GPS.

In addition, no sensitive data will be transmitted over the Internet.

The method also allows a comfort and time savings by selecting location-relevant data through the specific destination instead of time-consuming operation of an additional, different application on the user's terminal.

There is also a direct transfer of multivalued information, without a detour via primary reference data (BLE beacon UUID / location) and secondary data connections.

The method allows optional filtering of data from a variety of offered data. Thus, only the information of interest to the user is displayed and / or further processed on his terminal like a smartphone.

From a technical point of view, there are advantages in creating message and signature capabilities for implementing common authentication methods. In addition, a reduction of the receiver-side energy requirement is achieved by optimizing the scan rate, filtering the data according to message classes or message types, and by using a message ID.

Furthermore, a relief of the mobile network is achieved by avoiding simultaneous, redundant data requests.

In the solution according to the invention, the approach described above is followed, to divide a message into several segments and to send them sequentially, continuously via BLE Advertising. Hereinafter, the differences and advantages of the present invention in comparison with that of WO 2014 087192 A known prior art.

• 1. Verschiedene Nachrichten lassen sich nicht eindeutig voneinander unterscheiden.
• 2. Die steigende Ineffizienz des Verfahrens bei zunehmender Nachrichtenlänge wird nicht adressiert.
• 3. Das Verfahren liefert dem Empfänger keine Anhaltspunkte zur Optimierung seiner energieintensiven Scanoperationen.
• 4. Fehlende Nachrichtenklassifizierung erschwert Filterung, Erweiterbarkeit und Flexibilität.

A segment header known from the prior art, in particular according to the WO 2014 087192 A , which consists of only one segment ID and the total number of segments, has the following shortcomings:

• 1. Different messages can not be clearly distinguished.
• 2. The increasing inefficiency of the method with increasing message length is not addressed.
• 3. The method provides the receiver with no evidence to optimize his energy-intensive scanning operations.
• 4. Missing message classification makes filtering, extensibility and flexibility difficult.

To distinguish different consecutive messages 1 could be the number of segments 6 can be used, provided it actually changes depending on the new message length. A randomly equal number of segments 6 two consecutive messages 1 could also be excluded by rule. To comply with this rule would then in the case of an equal number of segments 6 consecutive messages, additionally one or more empty segments are added to the message. However, this reduces the efficiency of the process and also does not preclude a third message 1 coincidentally the same number of segments 6 as a first message has.

• • Eindeutige Unterscheidung verschiedener Nachrichten 1
• • Die Möglichkeit der Aufteilung langer Nachrichten 1 in Teilnachrichten erlaubt eine Effizienzsteigerung
• • Der Empfänger kann energieintensive Scanoperationen pausieren, sobald er alle momentan gesendeten Nachrichten 1 vollständig empfangen hat.

To solve the deficiencies in items 1 to 3, there is an additional field in the segment header 3 Required: the message ID 4 , Every new message 1 gets a new message ID 4 For example, by incrementing the previous message ID 4 , This results in the following advantages:

• • Unique distinction of different messages 1
• • The possibility of splitting long messages 1 in sub-messages allows an increase in efficiency
• • The receiver can pause energy-intensive scan operations as soon as it receives all messages currently being sent 1 has received completely.

To detect a new message 1 Suffice a battery-saving, occasional scan. As soon as any segment 2 a new message 1 is detected, the scan frequency can be maximized again until the rest of the new message 1 was received.

To solve the deficiencies in the points 3 and 4 is the inclusion of another field in the segment header 3 required: the message type 7 , This message type 7 represents a label that the message 1 belongs to a particular use case, to a particular service or product or to a particular manufacturer. In addition, the message type 7 also indicate a message format deviating from the standard format. In this way, it is possible for the recipient to filter for specific applications, services, products or manufacturers. At the same time, analogous to the message ID 4 , The scan rate are lowered battery-saving, as long as the receiver / user of interest messages 1 corresponding use cases, services, products or manufacturers.

The foregoing features and advantages of this invention should be better understood and appreciated after a thorough study of the following detailed description of the preferred non-limiting example embodiments of the invention herein, together with the accompanying drawings, in which:

1 : a schematic representation of a segmentation by means of an example,

2 : an example of a segment header format according to the present invention,

3 : a further embodiment of a segment header format according to the invention,

4 FIG. 3 shows a third exemplary embodiment of a segment header format according to the invention, FIG.

5 : an example of a transmission pattern of a single message,

6 : an example of a transmission pattern of two messages by means of a multiplex method,

7 : a reception algorithm for a data packet by means of the method according to the invention,

8th : an algorithm for prefiltering a data packet and

9 : an exemplary message format used in the invention.

In the sense of the method described here, the term "short message" is used to refer to a message, that is to say a data record, having a length of up to a maximum of 200 to 250 bytes. Longer messages can also be transmitted according to the method, but the efficiency of the described method decreases with the length of a message 1 from. Generally, the shorter the message 1 , the more efficient and faster it can be transmitted.

According to the method, the message length of a message to be transmitted 1 , which also as original message 1 is designated N bytes, where one segment 2 is provided, which can accommodate a maximum of M bytes payload, which corresponds to a so-called segment capacity.

According to the invention, a division of the message takes place 1 on several segments 2 , The first segment 2 with the designation "Segment0" thus contains the bytes [0 ... M-1] of the original message to be transmitted 1 , A first segment 2 temporally following second segment 2 with the term "Segment1" thus contains the bytes [M ... 2M - 1] of the message to be transmitted 1 , The next, third segment 2 labeled "Segment2" contains the bytes [2M ... 3M - 1] and so on. This division of the bytes of the message to be transmitted 1 will continue until all bytes of the message 1 in their respective segments 2 are housed. In this division, the data capacity of the last segment 2 not be fully exploited. A full utilization of the last required segment 2 is given only for the exemplary case that the message length N is integer divisible by M. The number of times for a message 1 required segments 2 So depends on message length N and the segment capacity M.

In the 1 is this division or segmentation of an original message 1 into individual segments 2 , also referred to as segmentation, is exemplified by way of example with a message length of N = 190 bytes and a segment capacity of M = 20 bytes. The illustration shows that the 190 bytes long original message consisting of the bytes 0 to 189 1 be divided into the segments 0, 1, ..., 9. Each of these segments 0 to 9 has a prefix header 3 on. These headers 3 are in the 1 designated H0 to H9. The format of this header 3 "Hx" is described in the following section.

• 1. Nachrichten-ID 4: ermöglicht Unterscheidung verschiedener Nachrichten
• 2. Segment ID 5: dient der eindeutigen Segment-Identifizierung
• 3. Segmentanzahl 6 (Anzahl Segmente der Nachricht 1): ermöglicht Feststellung der Vollständigkeit im Empfänger
• 4. Nachrichtentyp 7: Klassifizierung des Nachrichteninhaltes, Kennzeichnung eines speziellen Anwendungsfalles, Services, Produkt oder Herstellers, Hinweis auf Nachrichtenformat oder auf weitere Formatangaben innerhalb der Nachricht 1.

In the header 3 a segment 2 the following information is included in a first variant:

• 1. Message ID 4 : allows differentiation of different messages
• 2nd segment ID 5 : is used for unique segment identification
• 3. Segment number 6 (Number of segments of the message 1 ): allows to determine completeness in the recipient
• 4. message type 7 : Classification of the message content, identification of a specific use case, services, product or manufacturer, indication of message format or further format information within the message 1 ,

• 1. Nachrichten-ID 4: ermöglicht Unterscheidung verschiedener Nachrichten
• 2. Segment ID 5: dient der eindeutigen Segment-Identifizierung
• 3. Segmentanzahl 6 (Anzahl Segmente der Nachricht): ermöglicht Feststellung der Vollständigkeit im Empfänger
• 4. ein der Nachrichten-ID 4 vorangestellter Segmentheader-Typ

In the header 3 a segment 2 In a second variant, the following information is included:

• 1. Message ID 4 : allows differentiation of different messages
• 2nd segment ID 5 : is used for unique segment identification
• 3. Segment number 6 (Number of segments of the message): allows determination of completeness in the recipient
• 4. one of the message ID 4 prefixed segment header type

In the 2 is an exemplary first variant of a header implementation with the information Message ID 4 , Segment ID 5 , Number of segments 6 and message type 7 shown. In this exemplary embodiment, for the sake of simplicity, exactly one byte has been reserved for each piece of information. It is also conceivable, depending on practical considerations, to reserve less than 8 bits for individual header fields according to the expected data characteristics and for the purpose of the optimization. However, once a header format has been introduced in practice, it may not be changed, otherwise incompatibilities would arise which would render the method inoperable.

The only differentiation would be in such a case only a different company identifier in the advertising package. As a result, different manufacturers can use different header formats.

In the 3 and 4 become two further embodiments of the segment header 3 shown. With the help of another field called "Segment Header Type" 27 is the structure of messages with a variable length for the segment header 3 possible.

For a value of segment header type == 0, a segment header length of two bytes is defined. As in 3 shown, the fields are message ID 4 , Segment ID 5 and number of segments 6 in a 2-byte segment header 3 contain. This version of a segment header 3 is then advantageous if no information regarding message type 7 are required and a message format, such as plain text, as well as a character set, such as ASCII, are implicitly predefined for the case of 2-byte segment headers (ie, segment header type == 0). Like in the 3 and 4 shown, give the message ID 4 and the segment header type 27 in total a size of 8 bits or one byte. Thus, in a message ID 4 if a byte is reserved for this, a segment header type 27 be housed without the total size of the header 3 to change.

For a value of segment header type == 1, a segment header length of three bytes is defined. As in 4 shown, the fields are message ID 4 , Segment ID 5 , Number of segments 6 and message type 7 in a 3-byte segment header 3 contain. This version of a segment header 3 is then advantageous if information regarding message type 7 needed.

The message type 7 especially in a 3-byte segment header 3 a particular use case, product, service or manufacturer, and / or contains information about the data format, such as 'plain text' with character set, for example, latin-1 / ascii / utf8, or information about the encoding format of the message. The message type 7 may include information about the type of checksum used for authentication or the type of signature. In another embodiment, the message type 7 to further such information in the message header 8th refer.

Like in the 2 For example, a segment header format may be provided with one-byte information for the message ID 4 , the segment ID 5 , the number of segments 6 as well as the message type 7 to get voted. The header 3 be in the following time 2 exemplarily a maximum of 20 bytes of user data in one header 3 following segment 2 transfer.

The message type 7 as part of the header 3 fulfills several tasks. A first task is to identify that the message belongs to a particular use case, to a particular service or product, or to a particular manufacturer.

This fact allows the receiver to filter for desired parameters or content. If message segments of a message type 7 received, which are uninteresting for the user, the receiver can already after receiving a single segment 2 this message type 7 For example, reduce its scan rate or sampling rate and thus save energy. When in the low scan rate state, a segment 2 a message type of interest to the user 7 is received, the receiver can increase the scan rate again to all remaining segments 2 to receive the message of interest quickly and completely.

In a particular embodiment, the message type 7 Also contain an indication of a particular message format, which may differ from the agreed standard format. After recognizing the different message format this can then be used for the subsequent data transfer.

The method optionally sees the possibilities of an (authenticated) signature and / or encryption of the message 1 in front. In these cases, signature calculation and authentication take place for an original message 1 and / or encryption of the original message 1 before splitting the message to be transmitted 1 in segments in the transmitter. Parameter for identifying and describing a signature and / or encryption of a message 1 are in message type 7 or message header 8th contain and be before splitting a message 1 set in segments in the transmitter accordingly.

By means of the header 3 transmitted message ID 4 becomes a distinction between different messages 1 guaranteed. This is particularly important in the temporal multiplexing of various messages described below 1 and the associated performance advantages.

The original message in a sender 1 is divided into several segments as required 2 divided and sent according to a rule according to a specific pattern and repeated continuously. The goal of these repetitions is to create some redundancy since the transmitter neither receives the transmitted segments 2 in a receiver can still determine its completeness in the transmission of a message to a recipient.

In addition, there is a requirement that the message 1 using an optimized transmission pattern as fast as possible. This goal is then achieved as soon as the message 1 could be received with sufficient probability within a period acceptable to the application.

Under laboratory conditions, a pattern was determined which covers each segment 2 sends multiple times, as well as the complete message 1 repeated.

For example, in a time frame of 100 ms each segment 2 with its prefix header 3 sent twice and then to the next segment 2 advanced. After the last segment 2 will be back with the first segment 2 began.

In the 5 this process is exemplified. Starting with the segment 2 with the designation "Segment0", which at the time t = 0 seconds and t = 0.1 seconds, with its prefix not shown 3 , will be sent four different segments 2 sent consecutively. After the segment 2 The term "Segment0" becomes the segment at time t = 0.2s and t = 0.3s 2 followed by "Segment2" at time t = 0.4s and t = 0.5s and "Segment3" at times t = 0.6s and t = 0.7s. Subsequently, the process described is repeated in the same sequence of segments 2 ,

It is understood that such a procedure of a transmission process is only one possible advantageous embodiment. The described method could also without a repetition of a segment 2 or expire with more than two consecutive repetitions. Similarly, it is understood that each segment 2 with its associated prefix header 3 is sent or transmitted, even if not with respect to each segment 2 is described separately.

Another useful alternative is the multiplexing of at least two different messages 1 , Here, the messages to be transmitted 1 initially be sent sequentially. Only after sending the last message 1 begins the repetition of the entire sequence from the beginning. An example of this is in the 6 shown.

In the 6 is a sequence with a first message 1 labeled "message0" and a second message 1 shown as "message1". For example, the "message0", which is on three segments 2 has been divided with the segment IDs 0, 1 and 2, sent such that each segment 2 is repeated once, with the segments 2 one after the other in the order of your segment IDs 5 be sent in chronological order. After the "message0" has been sent, the message "message1" follows, which is divided into two segments 2 with the segment IDs 5 0 and 1, in the manner described for "message0". Afterwards, the transmission of the messages is repeated 1 continuously. A limitation to the two messages described in the example 1 does not exist.

Especially with regard to a decreasing efficiency of the method with high message length, eg in the case of long lists on scoreboards at airports (departure / landing / check-in), or in the case of central departure or arrival indications at stations (train / bus / tram), this is Multiplexing different messages 1 advantageous. If, for example, only two to three elements (train connections / flights) of the displayed list are accommodated in a BLE message, then the likelihood is higher that the information of interest to the user, for example via a specific traffic connection, will be received faster and more reliably than if only all segments 2 a relatively long message 1 (all elements of the displayed list) must be received before they can be displayed to the user or otherwise processed.

In a practical test were with the described patterns of 3 and 4 Transmission rates of approx. 60 to 80 bytes / s achieved.

The parameters determined under laboratory conditions, such as time grid, number of segment repetitions and multiplex forms, are not to be understood as constant and can be adapted to specific applications or to practical requirements.

It is intended that a message 1 usually sent repeatedly as long as it is valid. It is up to the sender and the application to decide which messages 1 how long to send, as well as whether concurrently valid messages are sent in a multiplexing process. In any case, it ensures that consecutive messages 1 using different message IDs 4 can be distinguished from each other.

To ensure that the recipient can receive advertising packets, the receiver must operate in a so-called scan mode in which he receives all BLE advertising packets from transmitters or devices from his environment. The received packets are searched for advertising data structures of the type 'manufacturer specific data'. If corresponding AD structures are found, and if the company identifier matches the sought-after value (application-specific), then these data are processed accordingly in a unit arranged in the receiver.

An optional step will now be based on the message type 7 in the segment header 3 decided whether the received, of several segments 2 existing data packet, so the original message 1 , should be further processed at the receiver or not. If one of the two previous checks is against the further processing of the data packet, the data packet is already discarded at this point.

The 7 outlines the core of the described receive algorithm. For further processing of the data packets filtered in this way, the following information is given in the header 3 evaluated: message ID 4 , Segment ID 5 and the number of segments 6 , The receiver has a buffer which is used to buffer all segments 2 a message 1 serves.

First, based on the message ID 4 in step 12 Checks if there is a cache for the corresponding message 1 already created. If this is not the case, then in step 13 the cache for all segments 2 the message 1 according to the number of segments 6 (Header information) reserved. So it has to be the first segment 2 a new message 1 but not necessarily the segment ID 0.

In step 14 a check is made as to whether a particular segment ID 5 already received. Will in step 14 found that this is not yet present, the payload below the index of the segment ID 5 in step 15 stored in a buffer memory. In addition, the segment ID 5 in a suitable manner in the step 16 marked as received, which can be done for example by means of a flag or counter. Should be the same segment 2 the same message 1 already received earlier, so the new data packet is in the step 17 discarded and if necessary a duplicate counter is incremented by one. This procedure is optional and can be used for a statistical evaluation.

Then the receiver checks in step 18 if the message 1 is complete by determining whether for each segment 2 at least one data packet was received. If the exam is positive, then in step 19 a higher-level software layer informed. The message reception is hereby finished.

If the received message contains an (authenticated) signature, its checking is also carried out after determining the completeness of a message, ie after step 18 , The signature check takes place either in the reception algorithm or in a higher software layer, depending on in which layer relevant countercheck data, for example a public key of the alleged transmitter, are available. If necessary, parameters for the signature must consist of segment headers 3 and / or message headers 8th for the purpose of signature verification to a higher software layer.

The result of the signature check should also be transmitted to a higher software layer. Alternatively, the higher software layer may instruct the receiving algorithm to report only successfully verified messages to the higher software layer.

If a received message is encrypted, the decryption takes place after determining the completeness of a message, ie after step 18 , The decryption takes place either in the receive algorithm or in a higher software layer, depending on in which layer the key for decryption is available. If necessary, parameters must be encrypted from segment headers 3 and / or message headers 8th for the purpose of decryption to a higher software layer, step 19 , be transmitted.

After the content of the complete message 1 has been transmitted to the higher-level software layer and, if appropriate, the signature check and / or decryption has been carried out or, if appropriate, parameters for signature verification and / or decryption have been transmitted to a higher-level software layer, the receiver should have its buffer for the received message 1 delete, if from the application point nothing contradicts it.

Further processing of the received message 1 is responsible for the higher software layer. The message 1 could be displayed to the user, for example. Or the received information will be evaluated or further processed depending on the application. In particular, higher-level software layers decide whether the scan mode is for receiving additional messages 1 is maintained or whether it will be terminated first and, if appropriate, continued at a later date. This scan rate optimization can be done in step 20 respectively.

The message type 7 (Header information) is especially important for higher software layers. It is conceivable that higher-level software layers direct the recipient to certain message types 7 to filter or discard. In the 8th such a pre-filtering is outlined.

Like in the 8th is shown when receiving a new data packet in step 21 , below in the step 22 checked if the message type 7 of the received data packet is relevant. If this is the case, in step 23 Check if the message ID 4 associated message 1 already completely received. Is the message type 7 of the received data packet is not relevant, then the data packet in step 24 discarded and in the crotch 25 optional scan rate optimization performed. With this optimization, the scan rate can be reduced for the purpose of saving energy in the mobile terminal, since there are currently no relevant message types 7 be received.

Will in step 23 found that the relevant message 1 has not been completely received, so is in the step 26 the reception algorithm for the complete reception of the message 1 started, which already above for 7 has been explained.

Hereinafter will be another aspect regarding the message format of a message used in the invention 1 explained.

A message 1 can be next to the payload, which is in the segments 2 be split, alternatively additional information in a message header 8th via a message format used, a character set used, a coding or an optional signature.

Such an embodiment is in the 9 with a message 1 , which includes, by way of example, bytes 0 through 189. In this example, the additional information mentioned is in the message header 8th at the beginning of the message 1 accommodated. The message 1 Contains in the message header 8th several 1-bit fields, which are also flags 11 be designated and the components signature field 9 and format field 10 ,

These flags 11 are used, for example, for information with a binary character, that is, for example, information about a message representation in a plain text or a coding, that is, whether the message 1 was coded by means of an appropriate regulation or not.

The format field 10 serves in the case of a message 1 in clear text of the specification of the used character set. In the case of coding the message 1 contains the format field 10 a reference to a used coding table or coding rule.

The signature field 9 For example, you can specify the type and length of the signature. A value of 0 in the signature field 9 could mean, for example, that there is no signature. A value of 1 in the signature field 9 could mean that a cryptological hash function after the Standard SHA256 has been used.

One in the signature field 9 declared message signature 9a can, as in the 9 shown to be added at the end of the message. Alternatively, the message signature 9a also be transmitted at a position before the message payload or within the message payload.

When presented in the 9 it is an embodiment. The sequence of fields 9 . 10 and 11 can also be set differently. It can, for example, also on single or all fields 9 . 10 or 11 the message header at the beginning of the message 1 provided that the information contained in such fields already clearly from the message type 7 the segment header (s) 3 emerge. In addition, it should be noted that such a stipulated agreement can not change during operation.

Alternatively, there is also the possibility that the message format is completely over the message type 7 in the header 3 is defined and therefore no additional information in the message 1 needed.

news 1 or message content can be transmitted either in plain text or in a coded form. In the case of plain text transmission, both the sender and the recipient must use the character set of a message 1 be known, eg ASCII, UTF-8 or similar.

Information regarding the character set is in the message header 8th contain. The " Coding "of a message is interesting for applications in which often recurring texts, eg as names of stops, directions or destinations or as status information such as'drives','lands',' stands ready ',' delayed 'or' falls out 'occur. Such recurring texts are replaced by certain codes, thus reducing the message length. The encoding table present in the receiver allows for back translation and interpretation of a coded message 1 and thus their further processing or display for the user.

Such a coding of a message 1 is designed with close reference to an actual use case, ie a specific city, specific region, specific means of transport. It must be distinguishable from other codes or use cases. This distinction is ensured by either the message type 7 in the header 3 or a format specification in the format field 10 within the message 1 or alternatively by both. The coding offers the advantage of increased efficiency due to the significantly shorter message length compared to plain text.

A problem of the described method is that the receiver is the authenticity and integrity of a received message 1 can not determine. Thus, an attacker could send incorrect information or received messages 1 Send out again, either with manipulated data or in the original ("replay attack").

This scenario can be met with an asymmetric key pair consisting of a private and a public key. The private key is to be kept secret and is available in the transmitter. The public key is not secret and is in the receiver. Such a key pair serves both to encrypt a message 1 as well as the authentication and the proof of integrity (no change / manipulation) of a message 1 or their signature.

In the case of encryption, the public key is used for encryption and the private key for decryption. In the authentication use case, the private key is used to create an authenticated signature in the sender. The public key, however, allows verification of an authenticated signature in the recipient.

In common authentication methods, the hash sum of a message is first formed, which is then signed or signed by means of a private key. The result will be the message to be sent 1 attached. One currently considered safe hash function is SHA256 , The length of a with SHA256 formed hash sum is 256bit (= 32 bytes). The length of the result of the signature operation corresponds to the length of the input data, ie also 32 bytes.

With regard to the definition of a short message with a length of up to 200 ... 250 bytes, a short message appears suitable for being able to include an additional signature of 32 bytes.

For the described method of transmitting BLE short messages, the application case authentication is considered first. A prerequisite for this method to work is a secure channel from the source of the key to the sender so that the private key can be safely, that is encrypted and mutually authenticated, to the sender where it is stored. In addition, measures must be provided which prevent the private key from being read out of the transmitter. If, contrary to expectations, a private key should become known, it is advantageous for the secure channel to be available at any time from the location of the key generation to the transmitter, in order to quickly transmit the private key of a newly generated pair and store it in the transmitter , Thus, an unintentionally known private key is replaced by a new one, which prevents the misuse of the known private key or minimizes the time window for possible misuse. If the unintentional disclosure of a private key can not be ascertained or can only be determined with great difficulty, then the change of the key can be made at regular time intervals, such as weekly.

In the case of stationary information displays, it can be assumed that at least temporarily there is a data connection through which current data is transferred from a central data memory to the display. This data connection could additionally serve as a channel for the transmission of the private key.

As an alternative to the transmission of private keys from the place of key generation to the sender and the associated required protection of the key transmission path and the associated necessary measures against reading a private key from the sender can send a message 1 also signed on a central server with the private key and then the signed message 1 be transmitted via a channel (data connection) to the transmitter. For this alternative, a channel from the central server to the local sender is required whenever a new signed message 1 should be sent locally. The advantage of this alternative would be the whereabouts of the private key at a central location Location and associated reduced backup effort for the transmission and retention of a private key in the local transmitters. However, even with this alternative, a secured (mutually authenticated and encrypted) channel between the sender and the central server is required to prevent misuse, such as unauthorized signature requests.

The public key must be transferred from the place of key generation to the BLE receiver. Although the key is public, the source of the key must authenticate to the BLE receiver to deliver the key. In the event that the BLE receiver is a smartphone, it can be assumed that there is a high probability at least temporarily an Internet connection, which can be used as a channel for the transmission of the public key.

Encryption is initially not very obvious for the application of public information displays, since optically displayed information is also unencrypted. Therefore, information that is sent out via BLE Broadcasting and which at the same time is visually readable by anyone in sight should also be sent out publicly, ie not encrypted.

Nevertheless, use cases are conceivable in which the circle of recipients is to be limited. For example, if additionally non-public information is sent, or if recipient permissions are to be distinguished by groups, or if short messages are sent via BLE, without the presence of an optical information display or audible announcement.

The principle of asymmetric encryption (individual key pair per receiver) is not practical for the application as broadcasting (one sender, multiple receivers - at the same time), since the sender would have to send a message encrypted separately for each recipient with its public key. Apart from the expense of key management for a large number of recipients, one and the same content would have to be transmitted repeatedly in many cases. This contradicts the broadcasting principle.

Much more practical is the application of a symmetric encryption, so the use of the same key for encryption and decryption.

• • ein symmetrischer Schlüssel darf nur an berechtigte BLE Empfänger übertragen werden,
• • die Übertragung eines symmetrischen Schlüssels zum BLE Sender darf nur nach gegenseitiger Authentifizierung erfolgen und muss verschlüsselt durchgeführt werden,
• • sowohl für einen im BLE Sender als auch für einen im BLE Empfänger gespeicherten symmetrischen Schlüssel sind Maßnahmen gegen unbefugtes Auslesen vorzusehen.

The key distribution is the same as in the Authentication by Signature section. In addition:

• • a symmetric key may only be transferred to authorized BLE receivers,
• • the transmission of a symmetric key to the BLE transmitter is only allowed after mutual authentication and must be encrypted,
• • Measures against unauthorized reading must be provided both for a symmetric key stored in the BLE transmitter and for a symmetric key stored in the BLE receiver.

The scan rate describes how often a BLE receiver is in scan mode per unit of time. Since the scanning mode is associated with increased energy requirements, it is recommended to limit the frequency of the scan mode to a necessary minimum.

During the reception of a BLE short message, there should be a high or the maximum possible scan rate in order to receive the complete message as quickly as possible. On the basis of various factors, after receiving a complete message, it is possible to decide what the likelihood is of receiving further messages of interest to the user at the moment. If this probability is low, then the scan rate should be reduced. If these factors change and the result is a higher probability of interesting news, then the scan rate should also be increased. Once a segment 2 a message of interest 1 was received, should be until the receipt of the complete message 1 the maximum scan rate can be set.

The factors determining the likelihood of interesting news 1 determine, depend directly on the context and the application. For example, there are messages 1 of arrival and / or departure of a platform or a stop for a user only interesting when it arrives at the platform / stop ("when is my next train?"). This also applies to a change in the display (update / delay) or other messages that affect the connection, such as scrolling text on display as a BLE message or audible announcement as a BLE message.

For example, suppose arrival times are updated once per minute. After receiving the first interesting message on arrival at the platform, the scan rate can be reduced to eg 5 seconds every 20 seconds. Updating the ad also changes the message ID 4 in the segment header 3 , The reception of a single segment 2 with a new message ID 4 of the same transmitter is a reason to maximize the previously reduced scan rate to the new message 1 that is, the BLE message that matches the updated ad 1 to receive completely. If the arrival of the desired connection is approaching (eg <1 minute), then the scan rate could be set to eg 2 seconds every 5 seconds in order to receive status messages such as 'train in' or 'entry' in a timely manner.

If the user is finally on the train and it is to be expected that ads with BLE stations are also located within the train, then for a time window after the entry (eg 1 minute), an increased scan rate should initially be maintained with the goal being the ID the train as a BLE message to receive, for example, to confirm that the user is on the right train. Thereafter, the scan rate can be reduced again, since it can be assumed that only a few messages of interest to the user (for example list of upcoming stops) must be received promptly until the next stop or until shortly before the scheduled exit. Shortly before the scheduled exit, the scan rate should be increased to alert the user in good time to the departure at the next stop, if he so wishes.

The user's interest may also be derived from whether his mobile device is in his pocket like a smartphone or in his hand. Various sensors of the smartphone, e.g. Light sensor or accelerometer, can give clues.

• • Inhalt und Headerinformationen bisher empfangener BLE-Nachrichten
• • Nachrichten-ID 4 und/oder Nachrichten-Typ 7 empfangener Segmente von BLE-Nachrichten
• • Anwendungskontext (App)
• • Aufenthaltsort des Nutzers
• • Sensoren des Smartphones (Beschleunigungsaufnehmer, Lichtsensor, etc.)
• • Informationen, welche von anderen BLE Beacons stammen.

In summary, selected example factors are mentioned, which can be used to optimize the scan rate:

• • Content and header information of previously received BLE messages
• • Message ID 4 and / or message type 7 received segments of BLE messages
• • Application Context (App)
• • Whereabouts of the user
• • sensors of the smartphone (accelerometer, light sensor, etc.)
• • Information that comes from other BLE beacons.

The possibilities of the invention will be explained below with reference to several exemplary embodiments. In the case of a local traveler or commuter, the following information is provided: confirmation of actual departure times on reaching a stop, minimization of waiting times by early selection of various travel options when entering a station. The traveler receives the information that the subway in 2 Minutes, the alternative S-Bahn but only in 10 minutes, the traveler can, for example, decide to use the subway. This decision can be made by the traveler without first having to go to one of the possible platforms.

In the case of a user of a travel planning application, the integration of the BLE procedure into the application enables one or more dynamic updates by BLE stations at transfer points or in means of transport, corresponding to the actual travel course. For example, when the right mode of transport has been entered, the smartphone will display the message "You are on the right train, S3 direction <Destination>"; or notes "Exit in <n> stations".

In passenger transport, there are other benefits for passengers with myopia or visual impairments. Such user groups no longer have to go in the immediate vicinity of a visual display to decipher the displayed data. Text-to-speech features on smartphones can also audibly output the information received through BLE to the visually impaired.

But other groups of users also benefit from the early arrival of passenger information via BLE compared to display displays: there is no longer any need to struggle with crowds, for example in waiting areas or on platforms, around a display board or an information display to reach. This results in time savings and increased comfort. The time gained can lead to the passenger fulfilling consumer wishes during the waiting period, such as a newspaper, a snack, a coffee, etc. It is also conceivable that the application points out the passenger to appropriate bridging possibilities of his waiting time, for example with BLE received local dealer product information, such as "You have 10 minutes left before your train leaves. Now at XYZ on offer: ABC for € 1.23 ". The exact knowledge of the remaining waiting time can also be used to alert and prompt the passenger to get to the right platform in good time.

• • Filterung des eigenen Fluges nach vorher eingegebenen Referenzinformationen (Abflugzeit / Ziel / Flugnummer) oder nach einer Auswahl über per BLE empfangener Liste bei Ankunft am Flughafen. Dadurch erübrigt sich die wiederholte manuelle Suche auf einem vorhandenen Informationsdisplay. Außerdem werden für den Fluggast unwichtigen Informationen anderer Flüge weggelassen.
• • Anzeige von Fluginformationen des selektierten Fluges auf dem Smartphone-Display des Nutzers. Dies erübrigt das regelmäßige Aufsuchen und Ablesen eines Informationsdisplays (Polling).
• • Automatische Abfrage (Polling) im Hintergrund, Erinnerung/Alarmierung des Fluggastes bei Statusänderung, somit erübrigen sich manuelle Abfrage komplett.

In the airport scenario described above, flight information that is also sent via BLE in addition to the visual display can relieve the passenger with the corresponding smartphone application in the following tasks:

• • Filtering your own flight according to previously entered reference information (departure time / destination / flight number) or after selecting via BLE received list on arrival at the airport. This eliminates the need for repeated manual searches on an existing information display. In addition, for the passenger unimportant information of other flights omitted.
• • Display of flight information of the selected flight on the user's smartphone display. This eliminates the need to regularly visit and read an information display (polling).
• • Automatic query (polling) in the background, reminder / alarm of the passenger with status change, so manual query completely unnecessary.

Such discharges lead to the reduction of the stress factor, which has so far been conditioned by the passenger's regular duty of inquiry. A reassured passenger is generally more willing to consume than a troubled one. By knowing the upcoming waiting time, the waiting passenger can also be offered suitable product, service or gastronomy information, which is also available as BLE messages.

The independence of the BLE method from a data connection is becoming increasingly important in an airport scenario: Here, the likelihood of high data roaming charges for passengers would be particularly high.

LIST OF REFERENCE NUMBERS

1

 Message / original message

2

 Segment / data segment

3

 Header / segment header

4

 Message ID / message ID

5

 Segment ID

6

 segment number

7

 message type

8th

 message header

9

 signature field

10

 format field

11

 flags

12

Check message ID available, step 12

13

Reservation for cache, step 13

14

Check segment ID available, step 14

15

Save data packet in the buffer, step 15

16

Mark segment ID as received, step 16

17

Discard data packet, step 17

18

Check message completely, step 18

19

Information to higher software layer, step 19

20

Scan rate optimization (optional), step 20

21

Receiving a new data packet, step 21

22

Check message type relevant, step 22

23

Check message ID complete, step 23

24

Discard data packet, step 24

25

Alternative scan rate optimization (optional), step 25

26

Receive algorithm off 7 , Step 26

27

 Segment Header Type

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• WO 2014087192 A [0074, 0075]

Cited non-patent literature

• Standard SHA256 [0053]
• Standard SHA256 [0139]
• SHA256 [0149]
• SHA256 [0149]

Claims (12)

Method for transmitting a message, in which a transmission of the message ( 1 ) from a transmitter to a receiver by means of a Bluetooth low energy method (BLE), the message ( 1 ) before sending to multiple segments ( 2 ) and where each segment ( 2 ) one the segment ( 2 ) prefixed headers ( 3 ), characterized in that each header ( 3 ) at least one indication of a segment ID ( 5 ), which when merging the split message ( 1 ) the order of the segments ( 2 ). A method according to claim 1, characterized in that the to a message ( 1 ) associated segments ( 2 ) with their headers ( 3 ) such that each segment to be transmitted ( 2 ) with its header ( 3 ) is sent repeatedly at least twice consecutively, before a subsequent segment ( 2 ) of the same message ( 1 ) with its header ( 3 ) is sent in the same way until all segments ( 2 ) of the message ( 1 ) and the process starts over. Method according to claim 1 or 2, characterized in that the header ( 3 ) also an indication of a number of segments ( 6 ), which determines the number of times the message is divided ( 1 ) required segments ( 2 ) indicates. Method according to one of claims 1 to 3, characterized in that the header ( 3 ) also an indication of a message ID ( 4 ), which is used to uniquely distinguish different messages ( 1 ) and to distinguish between updated messages ( 1 ) is needed. Method according to one of claims 1 to 4, characterized in that the header ( 3 ) also an indication of a message type ( 7 ), which is a filtering of a message ( 1 ) allows for a use case, a service, a product or a manufacturer and an adjustment of a scan rate of the receiver. Method according to one of claims 1 to 5, characterized in that the message ID ( 4 ), the segment ID ( 5 ), the number of segments ( 6 ) and / or the message type ( 7 ) comprise in their sum an integer multiple of 8 bits. Method according to one of claims 1 to 6, characterized in that the segment header ( 3 ) a segment header type ( 27 ) includes. Method according to one of claims 1 to 7, characterized in that after sending the first message ( 1 ) a second message ( 1 ) is sent before the process starts again, the messages ( 1 ) different message IDs ( 4 ) exhibit. Method according to one of claims 1 to 8, characterized in that the message ( 1 ) a message header ( 8th ), for identifying a used message format, a used character set, a coding and / or a signature. Method according to one of Claims 1 to 9, characterized in that the message header ( 8th ) a signature field ( 9 ), a format field ( 10 ) and flags ( 11 ) includes. Method according to one of claims 1 to 10, characterized in that after the transmission of a message ( 1 ) in a receiver storing the messages ( 1 ) with her message ID ( 4 ) and that upon complete storage of all messages ( 1 ) associated segments ( 2 ) information to a higher software layer ( 19 ) is generated and output. Method according to one of claims 1 to 11, characterized in that the adjustment of the scan rate ( 20 ) of the recipient after a complete receipt of a message ( 1 ) or when recognizing segment headers ( 3 ) with a low relevance.

Images