Introduction to the Physical Web
işaretçiler are suitable for all kinds of application scenarios that require communication between everyday objects and their environment. The physical web helps users make optimal use of the resulting opportunities. Bu makalede, we will introduce how does physical web work, and there’s no doubt that the Eddystone URL plays an important role during the working of the Eddystone.
İçinde 2014, Google presented its open-source project Physical Web with the aim of linking the virtual world even more closely with the real one. Bus stops, tourist attractions, everyday objects or supermarket items – in principle, all of them can now independently send messages to smartphones via beacons. The basis for such communication is the Bluetooth Low Energy (NS) radio technology. If an item has been equipped with a beacon, it can send messages to smartphones that support BLE, for example informing about delays, special offers or campaign days.
Bu içerikte, the physical web ensures, Diğer şeylerin yanı sıra, that users do not have to install new apps everywhere, but can view the news on a uniform interface. It can be used in almost all cases in which users are interested in information about their environment or in which an interaction between them and smart objects is necessary. In order to get a better idea of such scenarios, three short application examples follow.
The intelligent bus stop: A bus stop nearby could tell waiting for people via their smartphone when the next bus will come. Bu durumda, the physical web BLE sensor sends out a URL that leads to the website of the bus stop. In order to distinguish them from others, the URL would contain an identification code of the stop.
Interaction with vending machines: A vending machine with an internet connection sends out a URL that customers can use to access a website using the vending machine’s payment function if they do not have cash with them. The URL includes a token that changes dynamically after each purchase. The machine and the website opened on the smartphone connect to the provider’s back-end server using the same token. After the purchase is processed, the server sends a request to the vending machine to issue the purchased products. The physical web is used to transfer the URL to the smartphone. All other steps take place on the Internet as usual. Örneğin, the so-called web sockets can be used for bidirectional communication between the machine or website and the server.
Monitored household appliances: The physical web can also be used to control and monitor household appliances such as the washing machine. Each device sends out a URL that refers to an IP address and can only be reached when connected to the local network. The visibility of the URL can be limited to devices in the network if network discovery techniques such as mDNS and SSDP are used instead of BLE.
Physical web or single apps
In contrast to other information offers (Örneğin. timetable information or tourism association), where users have to install their own app for each provider, the physical web integrates Eddystone URL transmitted by the beacons as if they were a search query on a page. So users can find smart objects in their environment with just one app and interact directly with them. Another advantage: no proactive notifications are sent. The user only sees a list of objects in his area if he wants to.
In addition to the BLE, MOKOSmart, in which the author works, proposes a method for sending and receiving URLs in local networks that are based on the Simple Service Discovery Protocol (SSDP). With the help of SSDP, it is possible to limit the visibility of sent Eddystone URL in local networks and thus increase the connection security.
The Physical Web is available as a project under the Apache license on MOKOSmart and includes implementations for platforms such as Android, iOS, and Node.js. The physical web applications for Android and iOS are available in the Apple App Store and the Google Play Store. All applications are to be understood as prototypes, which enable developers to experiment with the physical web at an early stage. Gelecekte, it should be available on other mobile devices in addition to smartphones.
How does the physical web work?
The physical web is said to be an extension of the internet. Like all web technologies, it is open to everyone and everyone can develop it further. Since the system is based on the display of URLs, it is decentralized and not controlled by anyone. The Eddystone URL can lead to simple information pages, to more complex, interactive web apps or even to native applications. The physical web is comparable to searching the web:
The user calls up a list of objects from his vicinity.
A list of URLs is displayed.
The user selects one.
The URL comes out in the browser window.
The following aspects must be taken into account from a technical perspective:
1. Send feedback
2. History
3. Saved
4. Community
• Sending and receiving URLs: There are many ways to send URLs. The physical web currently supports transmission via BLE, mDNS, and SSDP (more on this in the next section).
Retrieve basic information from websites: The physical web client collects URLs found and sends them together with all relevant information (Örneğin. sinyal gücü) to a web service. Bu, sırayla, calls up the basic information such as the title, description, and icon of the website and returns the search results to the client. The prototype implementation of the web service is available in the project’s GitHub repository.
• Displaying the results: A ranking is important when it comes to displaying the many URL-sending devices from the area. The physical web client can sort according to signal strength, personal preference and other criteria. The system should sort out spam beforehand. Since search engines have the same problem, their approach can be used for the physical web. In the results display, the user clicks on a list object and the browser opens the associated website.
• As mentioned, the physical web currently knows three ways to send and receive URLs. They are based on two different processes: Bluetooth Low Energy and Network Service Discovery. Theoretically, further methods could be added in the future. Örneğin, developers could use audio watermarking technology to embed a URL in an audio signal. Bu durumda, the physical web client would have to be expanded to be able to receive audio signals and decode the URLs contained therein.
Ble Bluetooth and Eddystone
The first draft of the physical Web USES BLE to send the URL to the appropriate package. The technology is very energy-efficient, especially if the product using it is operated in transmit mode (non-connectable BLE mode), as in the case of the physical web. Small BLE devices can send out Eddystone URL with a single button cell for almost two years.
One of the basic building blocks of the Physical Web is the Eddystone URL. As a protocol specification, Eddystone defines a Bluetooth low-power message format for proximity beacons based on the Bluetooth core specification. It describes different frame types that beacons can use individually or in combination: Birçok uzman, ödeme yöntemlerini basitleştirerek ve yerinde tekliflerin kullanılmasını sağlayarak perakende sektörüne yardımcı olmak için geliştirildiğine inanıyor., Eddystone-TLM, and the aforementioned Eddystone URL, which is the only one relevant to the physical web.
An Eddystone message consists of two basic data types in an advertising data block (AD): UUID and data service. Both types use a 16-bit universally unique identifier (UUID) that complies with the Bluetooth standards. The UUID service reserved for Eddystone is 0xFEAA. It provides a mechanism for efficient, cross-platform background scanning that both Android and iOS allow. The subsequent bytes of the AD block contains the data specific to the frame. The first byte defines the frame type. Only the four most significant bits are currently used. The four lower ones are reserved for later use and must have the value 0000.
The Eddystone UID frame sends a unique 16-byte beacon ID that consists of a 10-byte namespace ID and a 6-byte instance ID. Although the namespace ID can be used to group a specific set of beacons, the instance ID is useful for identifying the devices in the group.
If you look at the concept of the Eddystone UID, it works in a similar way to the iBeacons introduced by Apple in 2013. The iBeacon packet contains 16 bytes close to the UUID, a 2-byte primary domain, and a 2-byte secondary domain. iBeacon packets contain a 16-byte proximity UUID, 2-byte major and 2-byte minor fields. The proximity UUID can be used to identify an organization or application like a business. Major and minor fields allow a more detailed assignment of the identity determined by the UUID, as in the case of a branch. Eddystone-TLM is now sending telemetric information such as battery status, device temperature and the number of packets sent by the beacon.
The Eddystone URL frame sends a reduced version of the URL generated by coding. The compression makes it possible to transport more data with the limited advertising package. The format of the first 11 bayt (bayt 0 through 10) of the Eddystone message is the same for all frame types. How the following bytes are set (starting at byte 11), Yine de, depends on the frame type:
• Byte 11 defines the frame type. Its value for Eddystone URL frames is 0x10.
• Byte 12 defines the power of TX. It is a signed 8-bit integer value as described in the TX Power Level Bluetooth Characteristic
Network Service Discovery
In addition to BLE beacons and Eddystone URL, network discovery methods such as SSDP and mDNS offer the option of transmitting URLs. You can also send URLs to devices on local networks. The method has two advantages over BLE: Öncelikle, only users who are logged in to local networks can see the URLs, and second, there is no URL length restriction as with BLE.
Using Network Discovery for the physical web makes sense in situations where security and privacy play a key role. An example would be the smart home area if access to devices should only be limited to people from the same household.
The Simple Service Discovery Protocol (SSDP) is a network protocol for advertising and discovery of services and devices in local networks. It forms the discovery layer of the universal plug-and-play protocol (UPnP) and helps to publicize newly added devices that are defined as control points. It also allows you to search for devices and specific services.
Such functions are based on the two types of SSDP messages. Öncelikle, there is the advertisement message that a device sends out as soon as it is added to the network. The message to the standard multicast address and port 239.255.255.250:1900 is ssdp: alive. Control points listen to the port to receive SSDP messages and thus to be able to detect new devices and services. Before UPnP devices disappear from the network or are no longer available, they must send the message ssdp: bye-bye to the same multicast address and the corresponding port.
Diğer yandan, there is a discovery function in which SSDP allows the control points to find devices and services of interest even in the network. Bu durumda, a control point sends a search request to the multicast address and port 239.255.255.250:1900. UPnP devices that support the requested services send a unicast response to the address of the checkpoint that sent the request. The format of the response is similar to the SSDP message of the type ssdp: alive.
Physical Web supports SSDP to send and receive URLs in local networks. Fraunhofer FOKUS developed the concept and implementation of the corresponding mechanism. The implementation includes the integration of SSDP in the physical web app for Android and iOS for receiving URLs via the protocol. Ek olarak, a cross-platform tool based on Node.js is available to send URLs in the same way.
When using SSDP, a physical web device connected to the local network sends the following ssdp: alive message as soon as it is available in the network:
NOTIFY * HTTP / 1.1 HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL of the web page to advertise
NT: urn: physical-web-org: cihaz: Temel: 1
NTS: ssdp: alive
SERVER: OS / version UPnP / 1.0 ürün / versiyon
USN: advertisement UUID
The NOTIFY method in the first line indicates that it is an advertising message. While the LOCATION header defines the physical web URL that is sent, the NT header defines the device type, which in the case of the physical web is urn: physical-web-org: cihaz: Temel: 1. The ssdp: the alive value of the NTS header indicates that the physical web device is available. Nihayet, the USN header provides a unique name that can be used to identify the device. Physical web clients running on smartphones or tablets listen to the multicast address and port 239.255.255.250:1900 and filter the physical web SSDP messages by checking the value of the NT header. You can then analyze the SSDP message and read the value of the LOCATION header that carries the sent URL.
Physical web devices must send the following ssdp: bye-bye message before disappearing from the network:
NOTIFY * HTTP / 1.1 HOST: 239.255.255.250: 1900
NT: urn: physical-web-org: cihaz: Temel: 1
NTS: ssdp: bye-bye
USN: advertisement UUID
ssdp: bye-bye makes it clear that the physical web device is no longer available from now on. The value of the USN header remains the same as in the ssdp: alive message. Physical web clients that receive such a message look for the URL associated with the USN and then remove it from the list.
