Peripheral device guided collision avoidance

Abstract

One example discloses a peripheral device comprising: a radio receiver configured to receive a first set of audio packets transmitted from a first central device over a first wireless link and to receive a second set of audio packets transmitted by a second central device over a second wireless link; and a processor configured to predict a conflict between the first set of audio packets and the second set of audio packets based on a set of transmission scheduling parameters.

Description

Technical Field

[0001] The present specification relates to systems, methods, devices, apparatus, articles of manufacture, and instructions for conflict avoidance for peripheral device booting. Background Art

[0002] There are technical deficiencies in the techniques for conflict avoidance of peripheral device booting. Summary of the invention

[0003] According to an example embodiment, a peripheral device includes: a radio receiver configured to receive a first group of audio packets transmitted from a first central device on a first wireless link, and to receive a second group of audio packets transmitted by a second central device on a second wireless link; and a processor configured to predict a conflict between the first group of audio packets and the second group of audio packets based on a set of transmission scheduling parameters.

[0004] In another example embodiment, the first group of audio packets and the second group of audio packets are Bluetooth LE audio packets.

[0005] In another example embodiment, the first central device is configured to initially schedule when to transmit the first set of audio packets over the first wireless link; and the second central device is configured to initially schedule when to transmit the second set of audio packets over the second wireless link.

[0006] In another example embodiment, the set of transmission scheduling parameters includes a first set of transmission scheduling parameters received from a first central device and a second set of transmission scheduling parameters received from a second central device.

[0007] In another example embodiment, the processor is configured to request at least one of the first central device and the second central device to update one or both of the two sets of transmission scheduling parameters.

[0008] In another example embodiment, at least one of the first central device and the second central device is configured to update one or both of the sets of transmission scheduling parameters based on a request from the peripheral device.

[0009] In another example embodiment, at least one of the two sets of transmission scheduling parameters is a set of ISO parameters.

[0010] In another example embodiment, the ISO parameters include an ISO interval defining a time interval between transmissions of audio packets.

[0011] In another example embodiment, the ISO parameters include the number of sub-events scheduled within the ISO interval.

[0012] In another example embodiment, the ISO parameters include a flush timeout defining a maximum number of consecutive ISO intervals for transmitting a particular audio packet before the particular audio packet is discarded.

[0013] In another example embodiment, the processor is a priority encoder or a link controller.

[0014] In another example embodiment, the first wireless link is a gaming link and the second wireless link is a telephony link.

[0015] In another example embodiment, the processor is configured to predict a conflict based on the first set of transmission scheduling parameters and the second set of transmission scheduling parameters before the first central device transmits the first set of audio packets for the first time.

[0016] In another example embodiment, the processor is further configured to predict a collision prior to the second central device transmitting the second set of audio packets for the first time.

[0017] In another example embodiment, the peripheral device is a head mounted device.

[0018] In another example embodiment, the first central device is a dongle.

[0019] In another example embodiment, the second central device is a smartphone.

[0020] In another example embodiment, the peripheral device is at least one of a wireless earbud and / or a wireless speaker.

[0021] The above discussion is not intended to represent every example embodiment or every implementation within the scope of the current or future technology set.The drawings and the following detailed description also illustrate various example embodiments.

[0022] Various example embodiments may be more fully understood by considering the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 An example of a peripheral device (eg, a head mounted device) wirelessly coupled to a first central device (eg, a dongle) and a second central device (eg, a smartphone) is shown.

[0024] Figure 2 A first example schedule representing a first set of audio packets (e.g., a first audio stream for a game link) on a first wireless link between a peripheral device and first and second central devices in parallel with a second set of audio packets (e.g., a second audio stream for a phone link) on a second wireless link.

[0025] Figure 3 A second example schedule represents a first set of audio packets on a first wireless link between a peripheral device and first and second central devices (e.g., a first audio stream for a game link) in parallel with a second set of audio packets on a second wireless link (e.g., a second audio stream for a telephone link).

[0026] Figure 4 An example recurring pattern showing packet loss on the phone link due to collisions of consecutive packets (ie, sub-events) between the game link and the phone link.

[0027] Figure 5 An example of a protocol for a peripheral device to adjust transmission scheduling parameters for both a first set of audio packets (e.g., a first audio stream) received from a first central device over a first wireless link and a second set of audio packets (e.g., a second audio stream) received from a second central device over a second wireless link is shown.

[0028] Figure 6 Example group transmission scheduling parameters (eg, ISO parameters) for a game link and / or a telephony link are shown.

[0029] Although the present disclosure allows various modifications and alternative forms, the details have been shown in the drawings by way of example and will be described in detail. However, it should be understood that other embodiments other than the described specific embodiments are also possible. All modifications, equivalents and alternative embodiments falling within the spirit and scope of the appended claims are also encompassed. DETAILED DESCRIPTION

[0030] Figure 1 An example 100 shows a peripheral device 102 (eg, a head mounted device) wirelessly coupled to a first central device 104 (eg, a dongle) and a second central device 110 (eg, a smartphone).

[0031] In some example embodiments, the peripheral device 102 (ie, the receiver) is a gaming head mounted device. The peripheral device 102 includes various circuit systems (not shown) including an antenna, a radio transceiver, a processor, a memory, and a power supply.

[0032] In some example embodiments, the first central device 104 (ie, the first initiator) is a dongle 106 coupled to a personal computer 108. The first central device 104 includes various circuitry (not shown) including an antenna, a radio transceiver, a processor, memory, and a power supply.

[0033] In some example embodiments, the second central device 110 (ie, the second initiator) is a smartphone. The second central device 110 includes various circuit systems (not shown) including an antenna, a radio transceiver, a processor, a memory, and a power supply.

[0034] The Bluetooth LE Audio standard enables many new use cases that are not possible with regular Bluetooth (Bluetooth Classic). While there may not be an LE Audio profile, for gaming use cases, the flexibility of the LE Audio framework (link layer + host stack) allows new use cases beyond the standardized profiles. One such hypothetical use case is a gaming headset 102 use case with a parallel audio connection toward a phone using a single radio in the headset 102.

[0035] A first set of audio packets (eg, a first audio stream game link) is exchanged between the peripheral device 102 and the first central device 104 over the first wireless link 112. These packets may include forward channel game stereo audio packets and rear channel game mono audio packets.

[0036] A second set of audio packets (eg, a second audio stream telephony link) is exchanged between the peripheral device 102 and the second central device 110 over the second wireless link 114. These packets may include a forward telephony stereo audio packet stream and an optional rearward voice stream.

[0037] The dongle 106 as the first central device 104 acts as a first initiator, and the headset 102 acts as a receiver. The scheduling of the first set of audio packets (e.g., the first audio stream "Game Link") (e.g., LE Audio packets) on the first wireless link 112 is determined by the dongle 106. The precise timing of these Game Link audio packets (i.e., sub-events) depends on the crystal clock connected to the transceiver (e.g., LE Audio radio) in the dongle 106.

[0038] The smartphone as the second central device 110 acts as the second initiator, while the headset 102 remains the receiver. The scheduling of the second set of audio packets (e.g., the second audio stream "phone link") (e.g., LE audio packets) on the second wireless link 114 is determined by the phone 110. The precise timing of these phone link audio packets (i.e., sub-events) depends on a separate crystal clock connected to the transceiver in the phone 110.

[0039] Thus, in some example embodiments, audio is received simultaneously at the head mounted device 102 from both the phone 110 and the dongle 106. The two audio streams 112, 114 are mixed and played via the speakers, enabling the user to perhaps listen to music and hear the game audio at the same time. For example, the head mounted device 102 user can listen to music, receive a phone call, or privately chat with another gamer while simultaneously listening to a game link conversation. In other example embodiments, there can also be audio transmission (e.g., MIC) from the head mounted device to the dongle and / or phone. This may even be done in parallel.

[0040] In many example embodiments, the audio streams 112, 114 are all LE Audio streams, rather than regular Bluetooth streams.

[0041] Separate scheduling algorithms in both the first central device 104 (e.g., dongle initiator) and the second central device 110 (e.g., smartphone initiator) create two different schedules for transmitting and receiving audio packets to the peripheral device 102 (e.g., headset receiver). These schedules allocate a number of time slots for transmitting audio packets, including retransmission options. In LE Audio, the two audio streams 112, 114 are transmitted isochronously (ISO).

[0042] In some example embodiments, these schedules are repeated during each LE Audio defined ISO interval (or multiple ISO intervals for burst numbers greater than 1). Typical values ​​for ISO intervals for phone 110 connections are 7.5 ms and 10 ms or multiples of these values. The gaming link uses smaller values, such as 5 ms, in order to keep audio latency as low as possible.

[0043] Typically, end-to-end audio latency is a key metric for a gaming link. Audio latency should be as low as 20ms or even below 20ms to have an acceptable gaming audio experience.

[0044] An important contributor to audio latency is the transmission delay (i.e., wireless transmission delay between transmitter and transceiver, excluding audio processing or audio filter group delay). The transmission delay depends on several audio stream transmission scheduling parameters (e.g., ISO parameters as defined in the LE Audio standard, see also Figure 6 ), such as: ISO interval, which defines the time interval at which the schedule repeats itself); number of sub-events (NSE), which defines the number of sub-events that will be scheduled in each ISO interval; and refresh timeout, which defines how many consecutive ISO intervals can be used to transmit a packet before the packet is discarded.

[0045] Figure 2 A first example schedule 200 showing a first set of audio packets 202 (e.g., a first audio stream for a gaming link) on a first wireless link between a peripheral device 102 (e.g., a head mounted device) and first and second central devices 104, 110 in parallel with a second set of audio packets 206 (e.g., a second audio stream for a telephony link) on a second wireless link.

[0046] The first example schedule 200 shows the timing of game link sub-event pairs 204 and phone link sub-event triplets 208 (including acknowledgements) within both a first audio stream 202 and a second audio stream 206 that produce occasional conflicts. For example, a repeated conflict between a game link sub-event 210 and a phone link sub-event 212 is shown.

[0047] Typically, such conflicts are accidental, since the timing depends only on each of the central device 104, 110 clocks (e.g., of the phone 110 and the dongle 106), which are each independently derived from their own crystal. This also means that the two schedules are expected to drift apart at the rate of the mismatch between the two crystals.

[0048] Having overlap between sub-events means that the peripheral device 102 (e.g., a headset) needs to pick which device (i.e., phone 110 or dongle 106) to communicate with during those conflicting / overlapping sub-events. The peripheral device 102 (e.g., a headset) includes a priority encoder in the link controller for making this selection.

[0049] The central devices 104, 110 (e.g., of the phone 110 and the dongle 106) are not aware that there is a disagreement. Only the peripheral device 102 (e.g., a headset) is aware that there is a disagreement. Other central devices that were not selected will not see the acknowledgement from the peripheral device 102 (e.g., a headset) and will subsequently attempt to retransmit their audio packets.

[0050] In many gaming example embodiments, low latency is critical. In such LE Audio-based gaming applications, the transmission scheduling ISO parameters (e.g., refresh timeout and number of sub-events) of the LE Audio radio are set to minimum values ​​to optimize for low latency, thereby sacrificing margin for link robustness, resulting in more audio packet collisions.

[0051] In such gaming applications, adding a second central device 110 (e.g., a smartphone) connection is to not increase the number of lost game link audio packets. Therefore, the priority encoder in the headset 102 is configured so that the game link will have a higher priority than the phone link during scheduling divergence.

[0052] In some example embodiments, such occasional conflicts are generally acceptable, even if the gaming link always has a higher priority, as long as the telephony link has sufficient retransmission options.

[0053] Figure 3 A second example schedule 300 represents a first set of audio packets 302 (e.g., a first audio stream for a gaming link) on a first wireless link between a peripheral device 102 (e.g., a head mounted device) and first and second central devices 104, 110 in parallel with a second set of audio packets 306 (e.g., a second audio stream for a telephony link) on a second wireless link.

[0054] The second example schedule 300 shows the timing of game link sub-event pairs 304 and phone link sub-event triplets 308 within both the first audio stream 302 and the second audio stream 306 that produce continuous conflicts. Here, for example, all of the game sub-event pairs 304 sub-events are conflicting with all of the phone link sub-event triplets 308 sub-events 310, 312, 314, 316. This is unacceptable because the phone link does not have any retransmission opportunities for a long time.

[0055] These consecutive collisions occur due to drift between the independent crystal clocks of the first and second central devices. Under perfect but unrealistic link conditions, if the game link does not use all of its sub-events to transmit audio, such consecutive sub-event overlaps are still not a problem because the game link is "perfect" and does not require retransmissions. In this "perfect" case, only the first two sub-events of the phone link are colliding, and the third sub-event is still available for the phone 110 to retransmit its audio packet.

[0056] However, in reality, the gaming link has a non-zero packet error rate, and in such cases, packet errors on the gaming link will result in many lost audio packets on the telephony link.

[0057] Once the two central device schedules have drifted apart and are no longer completely conflicting, these conflicts / overlaps will disappear for a while and phone link retransmissions will become possible, however, these conflicts / overlaps will reappear and cause a noticeable disruption of the phone link. Also, while a limited number of lost audio packets can still be concealed by audio processing techniques (e.g., the LE audio standard includes a packet loss concealment algorithm), this also has its limitations and can result in noticeable audio artifacts and, if too many subsequent packets are missed, audio silence / blanking periods.

[0058] Figure 4 Example 400 recurring pattern showing packet loss on the phone link due to collisions of consecutive packets (i.e., sub-events) between the game link and the phone link. At a use case level, this problem manifests itself by having a phone link with good quality (meaning no audio loss), but every several minutes, the link quality degrades significantly for a period of time.

[0059] Example 400 shows the expected number of packet losses per second in the telephone link (at the headset 102) under the following example conditions: 1E-3 packet error rate for the gaming link; 1E-3 packet error rate for the telephone line; and a crystal mismatch of 10 PPM.

[0060] An example embodiment of a peripheral device configured to improve communication robustness with a set of central devices is now discussed. When more than one audio stream is received by the peripheral device, the peripheral device initiates dynamic switching of audio stream transmission scheduling parameters. An intelligent transmission scheduler in the peripheral device 102 (e.g., a headset receiver) can detect / predict sub-event conflicts and overlaps and request the central devices 104, 110 to change their transmission scheduling parameters.

[0061] Figure 5 An example of a protocol 500 is shown for a peripheral device 102 to adjust transmission scheduling parameters for both a first set of audio packets 112 (e.g., a first audio stream) received from a first central device 104 over a first wireless link and a second set of audio packets 114 (e.g., a second audio stream) received from a second central device 110 over a second wireless link.

[0062] The peripheral device 102 (e.g., a head-mounted device) is configured to predict possible audio packet conflicts due to overlap between sub-events of a first group of audio packets and a second group of audio packets, and then direct at least one of the first central device and / or the second central device to adjust a transmission schedule of the first group of audio packets and / or the second group of audio packets.

[0063] Because the peripheral device 102 (i.e., the head-mounted device) has more transmission scheduling parameter (e.g., ISO parameter) information than either of the central devices 104, 110 individually, the head-mounted device 102 checks the transmission scheduling parameters of both links 112, 114 and requires one or more of the central devices 104, 110 to update the transmission scheduling parameters at least once to avoid audio packet conflicts.

[0064] The peripheral device 102 does this proactively before any audio packet collision occurs, so as to prevent collisions before they occur by looking at the two overlapping TDMA schedules.

[0065] This can be considered as "dynamically switching" the audio connection parameters of either or both of the first link 112 (e.g., game link) and the second link 114 (e.g., phone link) by instructing the central device 104, 110 to adjust its connection transmission scheduling parameters. In some example embodiments, adjusting the transmission scheduling parameters of only one of the audio streams has minimal impact on audio latency.

[0066] Dynamic switching can be considered to consist of three basic steps: Step 1: detection is performed only by the peripheral device 102 (e.g., a head mounted device receiver); Step 2: the peripheral device 102 requests the central device 104, 110 to update the transmission scheduling parameters; and Step 3: the transmission scheduling parameters (e.g., PHY and other connection parameters) are actually updated by one or more of the central devices 104, 110.

[0067] In the model used to simulate the impact of conflicts between game link and phone link scheduling, the model predicts a reduction in the robustness of the phone link depending on the game link and phone link radio equipment parameters (ISO interval, number of sub-events and refresh timeout). In the case of a conflict, the model assumes that the game link has a higher priority than the phone link so that the game link is not impaired when the phone link is enabled.

[0068] During operation, due to clock drift, the game link radio schedule can completely overlap with the phone link schedule for long periods of time, such as Figure 3 as shown (i.e., each sub-event in the phone link overlaps with at least one sub-event in the game link).

[0069] If the ISO interval of the phone link increases, the payload length of the radio packets also increases, making the packets longer. Once the phone link packets are long enough, for each packet in the phone link, there will no longer be conflicting schedules between the game link and the phone link.

[0070] If the phone link ISO interval is a multiple of the game link's ISO interval, there will be a significant impact on the phone link, otherwise there will be no significant impact. Therefore, one solution is to reconfigure the ISO interval of the game link when the phone establishes an audio link with the headset 102. At this point, the headset 102 knows whether to expect a problem. It can decide to dynamically switch between the 5ms and 7.5ms ISO intervals of the game link. In other example embodiments, the ISO interval of the phone link can be reconfigured in addition to or instead of the game link reconfiguration.

[0071] While this may have an impact on the transmission latency of the gaming link of approximately 3ms, some example designs may choose to keep the latency the same at all times so that the dynamic switching can be implemented to be imperceptible to the user, or to strive for the lowest latency when possible and hide the increase / decrease in latency and mask the event (e.g., through voice prompts) when the phone link starts / stops.

[0072] Although over time the clock drift between the game link and the phone link will eventually cause scheduling conflicts from time to time, the phone link will no longer be continuously blocked.

[0073] In various example embodiments, dynamic switching occurs only once, as dynamic switching may result in brief audio interruptions. Alternatively, the central devices 104, 110 may also remember their transmission scheduling parameter settings since the last time they were connected to a particular peripheral device 102. In other example embodiments, if the switching is done at the application layer, audio interruptions may result. Adding procedures for dynamically switching ISO parameters to the LE standard may make such switching more seamless.

[0074] In some example embodiments, any audio interruption during dynamic switching may be masked by playing a voice prompt (e.g., such as is done when ANC is enabled or disabled in the head mounted device 102).

[0075] Figure 6 An example 600 set of transmission scheduling parameters (eg, ISO parameters) 602, 604, 606 for a gaming link and / or a telephony link are shown.

[0076] For example, switching between 5ms and 7.5ms ISO intervals for the game link works for 10ms, 20ms, and 22.5ms phone link intervals, but not for 15ms phone link ISO intervals: 15ms is a multiple of 5ms and 7.5ms. In this case, there are two options 610: first, use the 10ms game ISO interval; or second, use the 5ms game interval and increase the refresh timeout by 1 in the game link. The game link becomes more robust at the expense of a 5ms increase in latency. The benefit of the second option is a slightly lower transmission latency 608 compared to the first option.

[0077] This increased robustness can be used to equalize priority between the game link and the phone link in the event of a conflict: this reduces the link robustness of the game link, offsetting the effect of the increase in refresh timeout, but increases the link robustness of the phone link.

[0078] For a telephone link ISO interval of 30ms, by properly setting the number of sub-events (≥3), the problem of reduced link robustness may no longer occur: sub-events in the telephone link do not always conflict with sub-events in the game link and the telephone link.

[0079] The example embodiments described above may be applied to wireless gaming headsets, wireless gaming earbuds, communication headsets, wireless speakers, and similar audio-enabled devices that use wireless communications.

[0080] Unless a specific order is explicitly stated, the various instructions and / or operational steps discussed in the above figures may be performed in any order. Moreover, those skilled in the art will recognize that although some example instruction sets / step sets have been discussed, the materials in this specification may also be combined in various ways to produce other examples and should be understood within the context provided in this detailed description.

[0081] In some example embodiments, these instructions / steps are implemented as functional instructions and software instructions. In other embodiments, instructions can be implemented using logic gates, dedicated chips, firmware and other hardware forms.

[0082] When instructions are embodied as an executable instruction set in a non-transitory computer-readable or computer-usable medium, these instructions are implemented on a computer or machine programmed with and controlled by the executable instructions. The instructions are loaded to be executed on a processor (e.g., one or more CPUs). The processor includes a microprocessor, a microcontroller, a processor module or subsystem (including one or more microprocessors or microcontrollers), or other control or computing devices. The processor may refer to a single component or multiple components. The one or more computer-readable or computer-usable storage media are considered to be part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more non-transitory machine or computer-usable media as defined herein exclude signals, but such media may be able to receive and process information from signals and / or other temporary media.

[0083] It will be readily appreciated that the components of the embodiments as generally described herein and illustrated in the accompanying drawings may be arranged and designed in a variety of different configurations. Therefore, the detailed description of the various embodiments as represented in the figures is not intended to limit the scope of the present disclosure, but is merely representative of the various embodiments. Although various aspects of the embodiments are presented in the drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0084] The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics of the present invention. The described embodiments should be considered in all respects to be illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than this specific embodiment. All changes falling within the equivalent meaning and scope of the claims should be included within their scope.

[0085] References throughout this specification to features, advantages, or similar language do not imply that all features and advantages that can be achieved by the present invention should be or are in any single embodiment of the present invention. Rather, language referring to features and advantages should be understood to mean that a specific feature, advantage, or characteristic described in conjunction with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of features and advantages and similar language throughout this specification may (but does not necessarily) refer to the same embodiment.

[0086] In addition, the features, advantages and characteristics of the present invention described may be combined in any suitable manner in one or more embodiments. Based on the description herein, those skilled in the relevant art will recognize that the present invention may be practiced without one or more specific features or advantages of a particular embodiment. In other examples, additional features and advantages that may not be present in all embodiments of the present invention may be identified in certain embodiments.

[0087] References throughout this specification to "one embodiment," "an embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present invention. Thus, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may (but do not necessarily) all refer to the same embodiment.

Claims

1. A peripheral device, characterized in that: include: A radio receiver, the radio receiver being configured to: receiving a first set of audio packets transmitted from a first central device over a first wireless link, and receiving a second set of audio packets transmitted by a second central device over a second wireless link; as well as A processor is configured to predict a collision between the first group of audio packets and the second group of audio packets based on a set of transmission scheduling parameters.

2. The device according to claim 1, characterized in that: The first group of audio packets and the second group of audio packets are Bluetooth LE audio packets.

3. The device according to claim 1, characterized in that: The first central device is configured to initially schedule when to transmit the first set of audio packets over the first wireless link; and The second central device is configured to initially schedule when to transmit the second set of audio packets over the second wireless link.

4. The device according to claim 1, characterized in that: The set of transmission scheduling parameters includes a first set of transmission scheduling parameters received from the first central device and a second set of transmission scheduling parameters received from the second central device.

5. The device according to claim 4, characterized in that: The processor is configured to request at least one of the first central device and the second central device to update one or both of the two sets of transmission scheduling parameters.

6. The device according to claim 5, characterized in that: At least one of the first central device and the second central device is configured to update one or both of the sets of transmission scheduling parameters based on the request from the peripheral device.

7. The device according to claim 4, characterized in that: At least one of the two sets of transmission scheduling parameters is a set of ISO parameters.

8. The device according to claim 7, characterized in that: The ISO parameters include an ISO interval defining the time interval between audio packet transmissions.

9. The device according to claim 8, characterized in that: The ISO parameters include the number of sub-events scheduled within the ISO interval.

10. The device according to claim 8, characterized in that: The ISO parameters include a flush timeout defining a maximum number of consecutive ISO intervals for transmitting a particular audio packet before the particular audio packet is discarded.

11. The device according to claim 1, characterized in that: The processor is a priority encoder or a link controller.

12. The device according to claim 1, characterized in that: The first wireless link is a gaming link and the second wireless link is a telephony link.

13. The device according to claim 4, characterized in that: The processor is configured to predict the conflict based on the first set of transmission scheduling parameters and the second set of transmission scheduling parameters before the first central device transmits the first set of audio packets for the first time.

14. The device according to claim 13, characterized in that: The processor is further configured to predict the conflict prior to a first transmission of the second set of audio packets by the second central device.

15. The device according to claim 1, characterized in that: The peripheral device is a head-mounted device.

16. The device according to claim 15, characterized in that: The first central device is a dongle.

17. The device according to claim 16, characterized in that: The second central device is a smartphone.

18. The device according to claim 1, characterized in that: The peripheral device is at least one of a wireless earbud and / or a wireless speaker.

Images