Method and apparatus for audio service

Abstract

A method of operating a source device in a wireless communication system according to one embodiment of the present disclosure may comprise the steps of: transmitting pilot data to a sink device through device-to-device (D2D) communication; receiving, from the sink device, a framework performance report (FPR) generated in an audio service framework of the sink device on the basis of the pilot data; determining a D2D configuration set for each link on the basis of the FPR and required performance for a wireless audio service; and transmitting framework data to the sink device through D2D communication by applying the D2D configuration set.

Description

Method and device for audio services

[0001] The present disclosure relates to a device-to-device (D2D) communication method between devices for audio services.

[0002] The Internet is evolving from a human-centered network where humans generate and consume information into an IoT (Internet of Things) network where distributed components, such as objects, exchange and process information. IoE (Internet of Everything) technology, which combines IoT with Big Data processing technologies through connections with cloud servers, is also emerging. Implementing IoT requires technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology. Recently, technologies such as sensor networks, Machine-to-Machine (M2M) communication, and Machine-Type Communication (MTC) are being researched for connecting objects.

[0003] In an IoT environment, intelligent IT (Internet Technology) services that create new value for human life by collecting and analyzing data generated from connected objects can be provided. Through the convergence and integration of existing IT (Information Technology) with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0004] Meanwhile, with the development of digital technology, various types of electronic devices such as mobile communication terminals, smartphones, tablet PCs, notebooks, wearable devices, digital cameras, personal computers, or Internet of Things (IoT) devices are widely used. To support and enhance the functionality of these electronic devices, the hardware and / or software parts of the devices are continuously being developed.

[0005] Recently, various types of proximity services utilizing low-power discovery technology are being developed. For example, proximity services (or proximity communication services) are being developed that allow electronic devices in close proximity to quickly exchange data through a proximity network.

[0006] The present disclosure proposes a method for providing stable D2D wireless transmission for wireless audio services.

[0007] According to one embodiment, a method of operation of a source device in a wireless communication system may include: transmitting pilot data to a sink device via device-to-device (D2D) communication; receiving a framework performance report (FPR) generated in an audio service framework of the sink device based on the pilot data from the sink device; determining a link-specific D2D configuration set based on the FPR and the required performance for the wireless audio service; and transmitting framework data to the sink device via D2D communication by applying the D2D configuration set.

[0008] According to one embodiment, a method of operation of a sink device in a wireless communication system may include: receiving pilot data from a source device via device-to-device (D2D) communication; generating a framework performance report (FPR) in an audio service framework of the sink device based on the pilot data; transmitting the FPR to the source device; and receiving framework data from the source device via D2D communication to which a link-specific D2D configuration set determined based on the FPR and the required performance for the wireless audio service is applied.

[0009] According to one embodiment, a source device in a wireless communication system may include a transceiver; and a control unit. The control unit may control the transmission of pilot data to a sink device via device-to-device (D2D) communication, receive a framework performance report (FPR) generated by an audio service framework of the sink device based on the pilot data from the sink device, determine a link-specific D2D configuration set based on the FPR and the required performance for the wireless audio service, and control the transmission of framework data to the sink device via D2D communication by applying the D2D configuration set.

[0010] According to one embodiment, a sink device in a wireless communication system may include a transceiver; and a control unit. The control unit may receive pilot data from a source device via device-to-device (D2D) communication, generate a framework performance report (FPR) in an audio service framework of the sink device based on the pilot data, control the transmission of the FPR to the source device, and receive framework data from the source device via D2D communication to which a link-specific D2D configuration set determined based on the FPR and the required performance for the wireless audio service is applied.

[0011] A method and apparatus according to one embodiment of the present disclosure can adaptively adjust settings for D2D communication by taking into account the required performance and wireless channel environment required for wireless audio services.

[0012] FIG. 1 shows a system including a plurality of electronic devices according to one embodiment of the present disclosure.

[0013] FIG. 2 illustrates an example of an environment in which a plurality of audio devices communicate according to one embodiment of the present disclosure.

[0014] FIG. 3 illustrates an example for explaining the roles of a plurality of audio devices according to one embodiment of the present disclosure.

[0015] FIG. 4 is a drawing for explaining a D2D setting method for audio devices according to one embodiment of the present disclosure.

[0016] FIG. 5 illustrates a procedure for audio devices according to one embodiment of the present disclosure to initiate a wireless audio service.

[0017] FIG. 6 illustrates a procedure for wireless audio group configuration and wireless audio provisioning according to one embodiment of the present disclosure.

[0018] FIG. 7 illustrates a procedure for a wireless audio initiation process according to one embodiment of the present disclosure.

[0019] FIG. 8 shows an example of a pilot transmission according to one embodiment of the present disclosure.

[0020] FIG. 9a shows an example of a format of framework data according to one embodiment of the present disclosure.

[0021] FIG. 9b shows an example of a framework frame including framework data according to one embodiment of the present disclosure.

[0022] FIG. 10 is a diagram illustrating a D2D Retransmission Count field included in framework data according to one embodiment of the present disclosure.

[0023] FIG. 11 is a drawing for illustrating framework data according to one embodiment of the present disclosure.

[0024] FIG. 12 is a drawing for illustrating an example of a method for determining a D2D configuration set according to an embodiment of the present disclosure.

[0025] FIG. 13 is a flowchart illustrating a method for determining a D2D configuration set according to one embodiment of the present disclosure.

[0026] FIG. 14 shows the configuration of a source device according to one embodiment of the present disclosure.

[0027] FIG. 15 shows the configuration of a sink device according to one embodiment of the present disclosure.

[0028] An embodiment of the present disclosure is described in detail below with reference to the accompanying drawings. In describing an embodiment of the present disclosure, if it is determined that a detailed description of related known functions or configurations might unnecessarily obscure the essence of the embodiment of the present disclosure, such detailed description is omitted. Furthermore, the terms described below are defined considering the functions in an embodiment of the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0029] It should be noted that technical terms used in this specification are used merely to describe specific embodiments and are not intended to limit any embodiment of this disclosure. Alternatively, unless specifically defined otherwise in this specification, technical terms used in this specification shall be interpreted in the sense generally understood by those skilled in the art to which this disclosure pertains, and shall not be interpreted in an overly broad or overly narrow sense. Alternatively, if a technical term used in this specification is an incorrect technical term that fails to accurately express the spirit of this disclosure, it shall be understood as being replaced by a technical term that can be correctly understood by those skilled in the art. Alternatively, general terms used in an embodiment of this disclosure shall be interpreted according to their prior definitions or according to the context, and shall not be interpreted in an overly narrow sense.

[0030] Alternatively, singular expressions used in this specification include plural expressions unless the context clearly indicates otherwise. In this application, terms such as "composed of" or "comprising" should not be interpreted as necessarily including all of the various components or operations described in the specification, and should be interpreted as meaning that some of the components or operations may not be included, or that additional components or operations may be included.

[0031] Alternatively, terms including ordinal numbers, such as first, second, etc., as used herein may be used to describe various components, but said components shall not be limited by said terms. Such terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, the first component may be named the second component, and similarly, the second component may be named the first component.

[0032] When it is stated that one component is "connected" or "connected" to another component, it may be directly connected or connected to that other component, or there may be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0033] Hereinafter, an embodiment according to the present disclosure will be described in detail with reference to the attached drawings. Identical or similar components regardless of drawing symbols are given the same reference number, and redundant descriptions thereof will be omitted. Alternatively, in describing an embodiment of the present disclosure, if it is determined that a detailed description of related prior art may obscure the essence of the present disclosure, such detailed description will be omitted. Furthermore, it should be noted that the attached drawings are intended only to facilitate understanding of the concept of the present disclosure and should not be interpreted as limiting the concept of the present disclosure. The concept of the present disclosure should be interpreted as extending to all modifications, equivalents, and substitutions in addition to the attached drawings.

[0034] Device-to-device (D2D) communication can refer to direct communication between two electronic devices in a mobile phone network without passing through a base station (BS) or a core network. For example, multiple electronic devices can perform D2D communication via cellular frequencies (e.g., inband) or unlicensed spectrum.

[0035] Recently, various types of proximity services utilizing low-power discovery technology are being developed. For example, proximity services (or proximity communication services) are being developed that allow electronic devices in close proximity to rapidly exchange data through a proximity network. Proximity services may include low-power proximity services using BLE (Bluetooth low energy) beacons, low-power proximity services based on Wi-Fi (wireless fidelity) low-power short-range communication technologies (e.g., NAN (neighbor awareness networking), Wi-Fi aware), proximity services based on Wi-Fi Direct, or proximity services based on UWB (ultra wideband).

[0036] According to one embodiment, an electronic device can provide proximity services (e.g., D2D (device to device) services) by establishing a direct communication connection (e.g., proximity network configuration) with an external electronic device located near the electronic device based on the various technologies described above.

[0037] D2D communication between electronic devices described in this disclosure can be performed based on at least one of BLE communication, Wi-Fi communication, Wi-Fi aware communication, Wi-Fi Direct, and UWB communication.

[0038] FIG. 1 shows a system including a plurality of electronic devices according to one embodiment of the present disclosure.

[0039] Referring to FIG. 1, the first electronic device (100) acts as a source device and can transmit (or broadcast) data to at least one sink device. The second to seventh electronic devices (110 to 160) act as sink devices and can receive data transmitted (or broadcast) from the source device.

[0040] In FIG. 1, for convenience of explanation, one source device and six sink devices are illustrated, but the technical concept of the present disclosure is not limited and the number of source devices and / or sink devices can be implemented in various ways.

[0041] Each of the first to seventh electronic devices (110 to 160) may be a device of various forms. For example, each of the first to seventh electronic devices (160) may include a portable communication device (e.g., a smartphone), a speaker, a wireless earphone, earbuds, a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The electronic devices according to the embodiments of this document are not limited to the devices described above.

[0042] For example, the first electronic device (100) may be implemented as a portable communication device (e.g., a smartphone, or a Bluetooth speaker) and may transmit (or broadcast) audio data via BLE. The second electronic device (110) and the third electronic device (120) may be implemented as a pair of wireless earphones worn on the user's left and right ears, respectively, and may receive audio data transmitted (or broadcast) from the first electronic device (100). The fourth electronic device (130) and the fifth electronic device (140) may be implemented as a pair of wireless earphones worn on the user's left and right ears, respectively, and may receive audio data transmitted (or broadcast) from the first electronic device (100). The sixth electronic device (150) and the seventh electronic device (160) may be implemented as a pair of wireless earphones worn on the user's left and right ears, respectively, and may receive audio data transmitted (or broadcast) from the first electronic device (100).

[0043] For example, each of the second electronic device (110) to the seventh electronic device (110 to 160) operates as an independent sink device and can independently receive audio data transmitted (or broadcasted) from the first electronic device (100).

[0044] The first electronic device (100) can transmit (or broadcast) configuration information necessary for each of the second electronic device (110) to the seventh electronic device (160) to receive data. Each of the second electronic device (110) to the seventh electronic device (160) can receive data based on the configuration information transmitted (or broadcast) by the first electronic device (100).

[0045] FIG. 2 illustrates an example of an environment in which a plurality of audio devices communicate according to one embodiment of the present disclosure.

[0046] Referring to FIG. 2, a first audio device (e.g., TV) (210) may transmit (or broadcast) the wireless audio data to each of the second audio devices (e.g., wireless speakers or soundbars) (220–260) using limited resources in order to share the wireless audio data with the second audio devices (e.g., wireless speakers or soundbars) (220–260). Each of the second audio devices (e.g., wireless speakers or soundbars) (220–260) may play the wireless audio data at a set timing.

[0047] The requirements for communication between multiple audio devices (210 to 260) may include at least one of the following 1) to 4).

[0048] 1) Transmission technology robust to changes in transmission and reception signal quality due to wireless environments

[0049] 2) Reliably transmit packets within the validity period in real-time data transmission

[0050] 3) Consider expanding connected devices by taking into account the channel capacity of wireless resources.

[0051] 4) Minimize interference with surrounding devices' use of wireless resources by considering the channel capacity of wireless resources.

[0052] The present disclosure proposes a pilot transmission method for defining a D2D configuration parameter set suitable for wireless audio transmission. When an electronic device transmits wireless audio, the wireless channel environment varies depending on the user environment and changes at each time interval, so a process of defining a D2D configuration parameter set suitable for the wireless channel environment may be necessary. Before starting a wireless audio service, it is required to define a pilot transmission step to determine and apply a D2D configuration set suitable for the user environment, and after the pilot transmission, the D2D configuration set can be determined based on a report received as feedback from a sink device.

[0053] Additionally, in the present disclosure, at least one of an Audio Service Framework, Frame Data, and Framework Frame that supports wireless audio transmission may be configured (or defined). According to one embodiment, it is necessary to configure (or define) a Framework Data format that can be used in wireless transmission without codec dependency. According to one embodiment, a format may be configured (or defined) for processing audio data in the Audio Service Framework by grouping or dividing it into units of transmission unit time or a specific number of audio packets for wireless transmission.

[0054] Additionally, the present disclosure may propose settings (or definitions) and related operations for a Framework Performance Report (FPR) and / or a D2D Performance Report (DPR). When audio data generated from a source device is wirelessly transmitted and played back at a sink device, performance and configuration parameters may be set (or defined) to estimate transmission environment factors affecting audio interruption and delay.

[0055] In addition, the present disclosure may propose a method for determining an optimal D2D configuration set utilizing FPR and / or DPR. According to one embodiment, an optimal D2D configuration set per link (source -> sink) may be determined based on the FPR of the sink device. According to one embodiment, a D2D configuration set that calculates the load on the D2D radio channel during audio service in a pre-configured D2D configuration and guarantees the transmission speed and / or transmission reliability for the audio service may be determined. According to one embodiment, a rule for determining an optimal D2D configuration set may be defined. According to the rule, for example, a D2D configuration set with high transmission reliability may be determined even if the transmission speed is low when audio interruption occurs. According to the rule, for example, a D2D configuration set that increases the transmission speed during high-quality audio and speaker expansion may be determined.

[0056] FIG. 3 illustrates an example for explaining the roles of a plurality of audio devices according to one embodiment of the present disclosure.

[0057] Referring to FIG. 3, the first audio device (310) acts as a source device and can transmit (or broadcast) audio data to a plurality of sink devices. The second to fourth audio devices (320 to 340) act as sink devices and can receive audio data transmitted (or broadcast) from the source device.

[0058] In FIG. 3, one source device and six sink devices are illustrated for convenience of explanation, but the technical concept of the present disclosure is not limited and the number of source devices and / or sink devices can be implemented in various ways.

[0059] Each of the first to fourth audio devices (310 to 340) may be a device of various forms. For example, each of the first to fourth audio devices (310 to 340) may include a portable communication device (e.g., a smartphone), a speaker, a wireless earphone, earbuds, a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The electronic device according to the embodiment of this document is not limited to the devices described above.

[0060] FIG. 4 is a drawing for explaining a D2D setting method for audio devices according to one embodiment of the present disclosure.

[0061] Referring to FIG. 4, the first audio device (410) may include an audio service framework (411), a D2D driver (413), and D2D firmware (415). The second audio device (420) may include an audio service framework (421), a D2D driver (423), and D2D firmware (425).

[0062] In operation ① of FIG. 4, the first audio device (410) can transmit audio data to the second audio device (420) via D2D communication through D2D firmware (415). The second audio device (420), having received the audio data, can transmit a DPR (D2D Performance Report) to the audio service framework (421) via D2D firmware (425) and a D2D driver (423) in operation ②. The DPR may be a report containing information on the performance of the D2D communication performed in operation ①.

[0063] In operation ③, the second audio device (420) can transmit a Framework Performance Report (FPR) to the first audio device (410) through the audio service framework (421). The FPR may be a report containing performance information that the audio service framework (421) evaluates by considering the DPR. Upon receiving the FPR, the first audio device (410) can transmit a Configuration Set to the D2D firmware (415) via the audio service framework (411) and the D2D driver (413) in operation ④. Subsequently, the first audio device (410) can again apply the Configuration Set to the D2D firmware (415) in operation ① and transmit audio data to the second audio device (420) via D2D communication.

[0064] FIG. 5 illustrates a procedure for audio devices according to one embodiment of the present disclosure to initiate a wireless audio service.

[0065] Referring to FIGS. 3 to 5, in order for the first audio device (310) to provide wireless audio services to each of the second audio device to the fourth electronic device (320 to 340), at least one of the first audio device to the fourth electronic device (310 to 340) may perform at least one of (1) a wireless audio group configuration step; (2) a wireless audio provisioning step; and (3) a wireless audio service initiation step. A detailed description of each of the steps (1) to (3) is as follows.

[0066] (1) Wireless audio group configuration step

[0067] The above wireless audio group configuration step may include all or at least some of the processes of 1) to 3) below.

[0068] 1) At least one of the first to fourth audio devices (310 to 340) can perform D2D-based device discovery.

[0069] 2) At least one of the first to fourth audio devices (310 to 340) can form a wireless audio group for a plurality of audio devices discovered through D2D-based device discovery. At least one of the first to fourth audio devices (310 to 340) can select a connected device and check the required performance. The required performance may refer to the audio transmission performance required by the audio device to support wireless audio services. For example, the required performance may include at least one of bit rate, codec latency, and PER (packet error rate).

[0070] 3) At least one of the first to fourth audio devices (310 to 340) can perform a D2D-based device connection procedure. For example, the first audio device (310) can perform a D2D-based device connection procedure with the second to fourth audio devices (320 to 340).

[0071] (2) Wireless audio provisioning step

[0072] The above wireless audio provisioning step may include all or at least part of the process 4) below. According to one embodiment, the wireless audio provisioning step may be performed after the wireless audio group configuration step.

[0073] 4) At least one of the first to fourth audio devices (310 to 340) can perform fitting for the D2D configuration parameter (at least one of the following processes (4a) to (4e) is performed).

[0074] (4a) At least one of the first to fourth audio devices (310 to 340) can initiate Framework Performance Measurement and / or D2D Performance Measurement.

[0075] (4b) The first audio device (310) can perform pilot transmission to each of the second to fourth audio devices (320 to 340).

[0076] (4c) Each of the second to fourth audio devices (320 to 340) can generate a Framework Performance Report (FPR) based on the pilot transmission and transmit it to the first audio device (310).

[0077] (4d) Determine and apply the Optimal D2D Configuration set by comparing the required performance with the Framework Performance Report.

[0078] (4e) Framework Performance Measurement, D2D performance measurement ends

[0079] (3) Wireless audio service initiation stage

[0080] The above wireless audio service initiation step may include all or at least some of the processes of 5) and 6) below. According to one embodiment, the wireless audio service initiation step may be performed after the wireless audio provisioning step. According to one embodiment, all or at least some of the processes of 5) and 6) below may be performed repeatedly.

[0081] 5) The first audio device (310) can transmit audio data to each of the second to fourth audio devices (320 to 340) via D2D communication.

[0082] 6) It can be confirmed that a low-quality service occurs in at least one audio service framework included in at least one of the first to fourth audio devices (310 to 340) (at least one of the following processes (6a) to (6e) is performed).

[0083] (6a) Each of the second to fourth audio devices (320 to 340) can initiate Framework Performance Measurement and / or D2D Performance Measurement.

[0084] (6b) At least one of the second to fourth audio devices (320 to 340) can transmit the FPR (Framework Performance Report) to the first audio device (310).

[0085] (6c) The first audio device (310) can determine an optimal D2D configuration set by comparing the required performance with the FPR.

[0086] (6d) The first audio device (310) may apply the optimal D2D configuration set determined in process (6c) during D2D communication. According to one embodiment, the first audio device (310) may apply the optimal D2D configuration set during D2D communication based on user input indicating user consent.

[0087] (6e) Each of the second to fourth audio devices (320 to 340) can terminate Framework Performance Measurement and / or D2D Performance Measurement.

[0088] FIG. 6 illustrates a procedure for wireless audio group configuration and wireless audio provisioning according to one embodiment of the present disclosure.

[0089] Referring to FIGS. 3 to 6, at least one of the first to fourth audio devices (310 to 340) can perform a wireless audio group configuration step and a wireless audio provisioning step.

[0090] <Wireless Audio Group Configuration Steps (Perform once initially)>

[0091] 1) At least one of the first to fourth audio devices (310 to 340) can perform D2D-based device discovery.

[0092] 2) The first audio device (310) may form an audio streaming group including the first to fourth audio devices (310 to 340) based on the D2D-based device discovery results. According to one embodiment, an audio service framework (311) within the first audio device (310) may form the audio streaming group and calculate (or determine) the wireless transmission requirement performance for the audio streaming group.

[0093] 3) The first audio device (310) can establish a D2D-based device connection with each of the second to fourth audio devices (320 to 340).

[0094] <Wireless Audio Provisioning Step (Performed once initially)>

[0095] 4) At least one of the first to fourth audio devices (310 to 340) can perform fitting for the D2D configuration parameter.

[0096] Each of the second to fourth audio devices (320 to 340) can start Framework Performance Measurement (FPM) and D2D Performance Measurement (DPM). Each of the second to fourth audio devices (320 to 340) can request the start of DPM when starting FPM.

[0097] The first audio device (310) can periodically transmit pilot data to each of the second to fourth audio devices (320 to 340). According to one embodiment, each of the second to fourth audio devices (320 to 340) can periodically measure D2D transmission performance during the pilot transmission of the first audio device (310) and report it to the audio service framework of the device.

[0098] Each of the second to fourth audio devices (320 to 340) can transmit (or provide feedback) a Framework Performance Report (FPR) to the first audio device (310). The FPR is a performance report in the Audio Service Framework (ASF) and may be a report including a DPR.

[0099] The first audio device (310) can determine and / or apply an optimal D2D configuration set. The first audio device (310) can determine an optimal D2D configuration set by comparing the required performance with the FPR and apply the determined D2D configuration set to the D2D firmware of the first audio device (310).

[0100] Each of the second to fourth audio devices (320 to 340) can terminate FPM and DPM. According to one embodiment, at least one of the second to fourth audio devices (320 to 340) can maintain FPM and / or DPM execution if there is no performance degradation when running FPR in the background simultaneously with the wireless audio service.

[0101] FIG. 7 illustrates a procedure for a wireless audio initiation process according to one embodiment of the present disclosure.

[0102] Referring to FIGS. 3 to 7, at least one of the first to fourth audio devices (310 to 340) can perform a wireless audio initiation step.

[0103] The first audio device (310) can transmit audio data to each of the second to fourth audio devices (320 to 340) based on D2D communication. According to one embodiment, the first audio device (310) can transmit framework data generated by the Audio Service Framework (ASF) to each of the second to fourth audio devices (320 to 340) based on D2D communication.

[0104] At least one of the second to fourth audio devices (320 to 340) can determine that a low-quality service is occurring based on audio data received from the first audio device (310). If at least one of the ASFs among the second to fourth audio devices (320 to 340) determines that the service quality is low, a fitting process for the D2D configuration parameter may be performed. According to one embodiment, at least one of the second to fourth audio devices (320 to 340) can determine whether a low-quality service is occurring by measuring the audio data of the wireless audio being transmitted instead of the pilot data.

[0105] At least one of the second to fourth audio devices (320 to 340) can start DPM (D2D Performance Measurement) and / or FPM (Framework Performance Measurement) and transmit FPR (Framework Performance Report) to the first audio device (310).

[0106] The first audio device (310) can determine an optimal D2D configuration set. According to one embodiment, the first audio device (310) can apply the D2D configuration set to D2D communication based on user input corresponding to user consent (where the user has consented to service quality improvement).

[0107] At least one of the second to fourth audio devices (320 to 340) may terminate the DPM and / or FPM. According to one embodiment, at least one of the second to fourth audio devices (320 to 340) may maintain the execution of the DPM and / or FPM if there is no performance degradation when running the FPR in the background simultaneously with the wireless audio service.

[0108] FIG. 8 shows an example of a pilot transmission according to one embodiment of the present disclosure.

[0109] In FIG. 8 (a) and (b), the first audio device (Device A) can operate as a source device in a wireless audio service, and the second audio device (Device B) can operate as a sink device in a wireless audio service.

[0110] The first audio device (Device A) can perform a pilot transmission based on parameters such as Modulation and Coding Scheme (MCS), Number of spatial streams, Preamble, Guard Interval, Space-Time Block Code (STBC), and Low-density parity check (LDPC) (which may vary depending on the Chipset) for a D2D configuration suitable for wireless audio transmission.

[0111] In FIG. 8(a), when the transmission unit is Normal, the first audio device (Device A) transmits a media access control protocol data unit (MPDU) to the second audio device (Device B), and the second audio device (Device B) transmits an ACK corresponding to the MPDU to the first audio device (Device A). Although it takes a long time for the first audio device (Device A) and the second audio device (Device B) to exchange at least one MPDU and at least one ACK, it can improve the reliability of wireless and device environment estimation.

[0112] In FIG. 8(b), when the transmission unit is Aggregated, the first audio device (Device A) transmits an RTS (Ready To Send, Request To Send, or transmission request) to the second audio device (Device B), and the second audio device (Device B) can transmit a CTS (Clear To Send, transmission permission, or transmission possible) corresponding to the RTS to the first audio device (Device A). Subsequently, the first audio device (Device A) transmits an A-MPDU (Aggregate-MAC Service Data Unit) to the second audio device (Device B), and the second audio device (Device B) can transmit a BA (Block Ack) corresponding to the AMPDU to the first audio device (Device A). When the first audio device (Device A) and the second audio device (Device B) exchange RTS / CTS / AMPDU / BA, it takes less time and the user's service experience can be improved.

[0113] The pilot transmission type proposed in this disclosure can be set to Best efficiency, Best throughput, or Best reliability.

[0114] The above Best efficiency can be defined by combining high-speed transmission and high-reliability transmission parameters. The above Best throughput (e.g., Spatial Multiplexing) is intended for high-speed transmission and can increase the number of spatial streams. The above Best reliability (e.g., Spatial Diversity) is intended for high-reliability transmission and can decrease the number of spatial streams.

[0115] Pilot data used during pilot transmission can be configured by inserting sample audio or dummy data into audio data to simulate audio transmission situations. Audio data can be transmitted by including it in the payload within the Framework Data Format.

[0116] FIG. 9a shows an example of a format of framework data according to one embodiment of the present disclosure.

[0117] Referring to FIG. 9a, the framework data may include a D2D Retransmission Count field, a Tx Timestamp field, an Rx Timestamp field, an Audio Channel field, a Frame Type field, a Frame Size field, a Frame Count field, a Packet Count field, a Packet Length field, and a Packet Data field. The Packet Data field may include Audio Data.

[0118] The D2D Retransmission Count field is

[0119] The number of retransmissions during D2D transmission can be recorded. The D2D Retransmission Count field can be updated in the D2D firmware.

[0120] The Tx Timestamp field can indicate the (host) framework timestamp of the source device.

[0121] The Rx Timestamp field can indicate the (host) Framework timestamp of the Sink device.

[0122] The Audio Channel field can indicate the audio channel of the Framework Data (e.g., Pilot-Data, All-Channel, FL, FR, etc.). The Audio Channel field can distinguish whether the data is All-channel or Specific-channel. In Pilot transmission, the Audio Channel field can indicate the use of Pilot-Data. The Audio Channel field can be used as metadata for matching the location of the Sink device with the audio channel.

[0123] The Frame Type field can specify the method used as a standard when assembling packets to form a frame (e.g., time based, packet count based). Time based can be selected when using the Codec's latency value.

[0124] The Frame Size field has a time or count value depending on the Frame Type, and the number of packets constituting one Frame may vary (for example, Frame Size = 32ms when Time-based, Frame Size = 6 when Packet count-based).

[0125] The Frame Count field can indicate the number of frames currently being transmitted. A frame can be a collection of packets.

[0126] The Packet Count field can indicate the number of packets currently being transmitted. For example, when 1 Frame = 6 Packets, the 203rd Packet can be indicated as Frame Count = 33 and Packet Count = 5.

[0127] The Packet Length field can indicate the length of the packet data.

[0128] The Packet Data field may contain Audio Data created by assembling audio frames (or audio packets) according to the Packet Length.

[0129] FIG. 9b shows an example of a framework frame including framework data according to one embodiment of the present disclosure.

[0130] Referring to FIGS. 9a and 9b, a framework frame may include at least one framework data. In FIG. 9b, as an example, a framework frame may include six framework data.

[0131] FIG. 10 is a diagram illustrating a D2D Retransmission Count field included in framework data according to one embodiment of the present disclosure.

[0132] Referring to FIG. 9a and FIG. 10, the D2D Retransmission Count field may be a field included in the Framework Data. An Audio Service Framework (ASF) included in the audio device generates (or determines) the Framework Data, and D2D firmware (e.g., Wi-Fi Module (Tx)) included in the audio device may count by +1 when a retransmission occurs and insert a count value into the D2D Retransmission Count field. A header (802.11 Header) may be attached to the front of the Framework Data processed by the D2D firmware (e.g., Wi-Fi Module (Tx)).

[0133] FIG. 11 is a drawing for illustrating framework data according to one embodiment of the present disclosure.

[0134] Referring to FIG. 9a and FIG. 11, the Audio Channel field included in the framework data may include at least one of Pilot-Data, All-channel, FL (front left), FR (front right), FC (front center), LFE (low frequency), BL (back left), or BR (back right). The Frame Type field included in the framework data may include Time based or Packet count based.

[0135] In an Audio Service Framework, audio data can be processed by grouping or dividing it into transmission time units or a specific number of audio data units to transmit audio data wirelessly.

[0136] For example, if the sampling rate is 48KHz, channel = 2 (stereo), and bit depth = 16-bit, then 1 audio frame size = 32[bit], 1 audio frame length = 20.83[us], 2[ch] * 16[bit] = 32[bit], and 1[s] / 48000 = 20.83[us]. If the Framework Frame Unit is defined as a unit of time, assuming audio frames are collected and transmitted over a 5ms unit of time, 5ms / 20.83us = 240.03, so approximately 240 audio frames can be transmitted. 240 audio frames can be defined as one packet of audio data (audio data) (e.g., 240 audio frames = 240 * 4B = 960B).

[0137] If the Framework Frame Unit is defined as the number of unit packets, for example, assuming that 250 audio frames are bundled for wireless transmission, the transmission packet size can be 250 * 4B = 1KB.

[0138] The DPR (D2D Performance Report) proposed in this disclosure may be a report created (or generated) by D2D firmware and transmitted to an Audio Service Framework. According to one embodiment, the DPR may be a report for informing an upper layer of IEEE 802.11-based transmission performance.

[0139] According to one embodiment, the DPR may include at least one of a Transmitter MAC Address field, a Sequence Number field indicating a MAC sequence number, a Received Signal Strength Indicator (RSSI) field indicating signal power, a Noise field indicating noise power, a Wi-Fi Class field indicating IEEE 802.11n, ac, ax, etc., an MCS index field indicating an index on a table where the Modulation Scheme and Coding Rate for each Wi-Fi Class are defined, and an Nss (Vss) field indicating the Number of Spatial Streams.

[0140] The Framework Performance Report (FPR) proposed in this disclosure may be a report created (or generated) by an Audio Service Framework and intended to provide feedback on transmission performance to the Audio Service Framework of a Source device. According to one embodiment, the FPR may be a report intended to request DPM while performing FPM when a Low Quality Service event occurs at a Sink device.

[0141] According to one embodiment, the FPR may include at least one of the following: a Device ID field indicating an identifier of an audio device (or sink device); a Frame Count field; a Packet Count field; a Transmission Delay field calculated by calculating the transmission delay (Rx Timestamp - Tx Timestamp) for a packet successfully received from the source device; a Frame Loss Rate field calculated by calculating the loss rate of a Framework Frame from the ASF; a D2D Retransmission Count field for transmitting the number of retransmissions from the D2D firmware (driver) of the source device in the Framework Data Format; an Arrival Time and Presentation Time GAP field indicating the difference between the time audio data arrives at the ASF of the sink device and the time it should actually be played; and a DPR (D2D Performance Report) field including a report uploaded from the D2D.

[0142] FIG. 12 is a drawing for illustrating an example of a method for determining a D2D configuration set according to an embodiment of the present disclosure.

[0143] An optimal D2D configuration set can be determined by calculating the load on the WLAN / D2D radio channel and ensuring the transmission speed and / or transmission reliability for the audio service.

[0144] Referring to Fig. 12, in an audio service where six framework data are included in one framework frame and defined, when there are three connected devices, WLAN / D2D radio data (Framework Data) can be transmitted.

[0145] At this time, since each connected device has a wireless link configured with an independent D2D configuration parameter set, there may be differences in transmission time depending on the wireless link. For example, a first audio channel (Link 1) may be assigned to a first audio device, a second audio channel (Link 2) may be assigned to a second audio device, and a third audio channel (Link 3) may be assigned to a third audio device.

[0146] The time intervals within the audio channel allocated to each audio device may consist of DIFS (Distributed Inter-Frame Space), Backoff, SIFS (Short Inter-Frame Space), time intervals for DATA (Framework Data) transmission, and time intervals for ACK transmission and reception.

[0147] The transmission time for each block and the backoff for channel access can be calculated. For example, in FIG. 12, if a framework frame is transmitted every 32 ms, and DIFS: 50 [us], Backoff: 67.5 [us], SIFS: 10 [us], DATA: 22.17 [us], ACK: 32 [us], then 31.25 framework frames are transmitted for 1 second for an audio service, and the time occupied in the wireless section can be 23.72 [ms].

[0148] If there are 3 connected devices, the time occupied in the wireless section can be calculated as 23.72 * 3 = 71.16 [ms]. As the number of connected devices increases, the probability of the Backoff Count for Channel Access increasing increases. Therefore, when calculating the transmission time per link, the probability of wireless packet collisions can be reduced by calculating with sufficient Backoff.

[0149] According to one embodiment, the transmission speed may vary depending on the Wi-Fi Class, MCS, etc., and the transmission time may vary, and the block configuration may be changed when using A-MPDU, etc.

[0150] According to one embodiment, to determine an optimal D2D configuration set, the following method may be established for at least one of channel access improvement, high-reliability transmission, and high-speed transmission.

[0151] <Channel Access 개선>

[0152] - Exclusively occupy channels by applying RTS / CTS / A-MPDU / BA at the Framework Frame level

[0153] - Change Radio Channel

[0154] High-reliability transmission

[0155] - Upward antenna radiation power

[0156] - Apply Spatial Diversity

[0157] - MCS Downward Adjustment

[0158] - MCS index optimization (using the MCS of a specific range or fixing the MCS)

[0159] High-speed transmission

[0160] - Transmission speed increases proportionally to the number of spatial streams by applying Spatial Multiplexing

[0161] - MCS upward adjustment

[0162] According to one embodiment, when the requirements of the audio service are High Resolution Audio, high-speed data transmission may be required by increasing the Sampling Rate and Bit Depth.

[0163] According to one embodiment, when the requirements of the audio service are multiple audio channels, high-speed data transmission may be required by increasing the wireless audio link through the expansion of audio channels.

[0164] According to one embodiment, using a configuration of RTS / CTS / A-MPDU / BA according to the requirements of an audio service can reduce the number of repeated channel accesses, thereby increasing Band Efficiency and achieving the goal of high-speed transmission. However, since using A-MSDU increases the frame error rate, only A-MPDU can be used while maintaining the MSDU size defined in the existing Audio Service Framework.

[0165] According to one embodiment, if Spatial Multiplexing is used in a MIMO environment according to the requirements of an audio service, the transmission speed can be increased in proportion to the number of Spatial Streams.

[0166] FIG. 13 is a flowchart illustrating a method for determining a D2D configuration set according to one embodiment of the present disclosure.

[0167] Referring to FIG. 13, in operation 1310, the first audio device (or source device) can diagnose a problem from the FPR received from the second audio device (or sink device). In operation 1320, the first audio device (or source device) can derive a D2D configuration set. In operation 1330, the first audio device (or source device) can calculate the transmission time (occupancy time) using the D2D configuration set. In operation 1340, the first audio device (or source device) can determine an optimal D2D configuration set.

[0168] If the first audio device (or source device) determines an optimal D2D configuration set (1340-YES), in operation 1350, the first audio device (or source device) can apply the optimal D2D configuration set to D2D communication.

[0169] If the first audio device (or source device) fails to determine an optimal D2D configuration set (1340-NO), in operation 1360, the first audio device (or source device) can adjust the D2D configuration set and perform operation 1330 again.

[0170] The first audio device (or source device) can determine the optimal D2D setting set for each Link (Source -> Sink) by referring to the FPR of the second audio device (or sink device).

[0171] According to one embodiment, in the case of FPR for Pilot Transmission, the Pilot Transmission transmits a data set for each D2D configuration set, so the optimal D2D configuration set can be determined at the first audio device (or source device) without DPR.

[0172] According to one embodiment, in the case of an FPR generated during an audio service, or in the case of no DPR, a D2D setting set for high-reliability transmission can be determined conservatively using the Frame Loss Rate and the Arrival Time and Presentation Time Gap.

[0173] According to one embodiment, the field value analysis of FPR can be performed as follows.

[0174] Transmission Delay refers to the time taken to transmit framework data from the source device to the sink device's framework after it is generated; a smaller delay indicates a more stable transmission environment.

[0175] - The larger the Arrival Time and Presentation Time GAP value, the more stable the transmission environment; if the value is small, there is a high possibility that audio data will be discarded and not played back.

[0176] - Retransmission Count is a record of the number of retransmissions in the D2D firmware (driver), and packets that failed to transmit may not have a Retransmission Count value.

[0177] - The higher the Frame Loss Rate, the more likely D2D frames are to collide or wireless signals may fail to reach the Sink device, in which case high-reliability transmission may be required.

[0178] - As transmission delay is low and retransmission count is high, channel access is good, but retransmissions may occur frequently, and in this case, high-reliability transmission may be required.

[0179] - As Transmission Delay is high and Retransmission Count is low, Channel Access may not be possible, so Channel Access improvement may be necessary.

[0180] - If Transmission Delay is high and Arrival Time and Presentation Time GAP is low, it indicates that wireless transmission delay has occurred, so it is necessary to check other indicators such as Retransmission Count.

[0181] - The lower the Transmission Delay and the lower the Arrival Time and Presentation Time GAP, the more likely it is that the generation of the framework packet from the source device has been delayed.

[0182] According to one embodiment, the analysis of the field value of DPR can be performed as follows.

[0183] - It complements FPR and allows you to intuitively check transmission failures and delays based on D2D configuration.

[0184] - By comparing the MCS and SNR of the transmitted packets, the lower MCS index can be used to determine whether to apply transmission reliability enhancement.

[0185] - If a lower MCS cannot be used, the use of Spatial Diversity may be considered.

[0186] FIG. 14 shows the configuration of a source device according to one embodiment of the present disclosure.

[0187] The source device of FIG. 14 may be implemented as the source device shown in FIG. 1 to FIG. 13, or as an audio device operating as a source device.

[0188] Referring to FIG. 14, the source device may include a processor (1401), a transceiver (1403), and a memory (1405). In the present disclosure, the processor (1401) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor (1401) may also be referred to as a control unit or a controller.

[0189] The processor (1401) can control the overall operation of the source device described in the embodiments proposed in this disclosure. Specifically, the processor (1401) can control the operation of, for example, the source device shown in FIGS. 1 to 13, or an audio device operating as a source device.

[0190] The transceiver (1403) can transmit and receive signals with other electronic devices or at least one sink device. The transceiver (1403) may also be referred to as a transceiver or a transceiver.

[0191] The memory (1405) can store at least one of the information transmitted and received through the transceiver (1403) and the information generated through the processor (1401).

[0192] According to one embodiment, the processor (1401) can control the transmission of pilot data to the sink device via device-to-device (D2D) communication. According to one embodiment, the processor (1401) can receive a framework performance report (FPR) generated by the audio service framework of the sink device based on the pilot data from the sink device. According to one embodiment, the processor (1401) can determine a link-specific D2D configuration set based on the FPR and the required performance for the wireless audio service. According to one embodiment, the processor (1401) can control the transmission of framework data to the sink device via D2D communication by applying the D2D configuration set.

[0193] According to one embodiment, the FPR may include at least one of an ID field indicating an identifier of the sink device, a Frame Count field, a Packet Count field, a Transmission Delay field calculating the transmission delay based on packets successfully received from the source device, a Frame Loss Rate field, a D2D Retransmission Count field indicating the number of data retransmissions of the source device, and a GAP field indicating the difference between the time audio data arrived from the sink device and the actual playback time.

[0194] According to one embodiment, the FPR may include a DPR (D2D Performance Report) generated based on the pilot data in the D2D firmware of the sink device. The DPR may include at least one of a Transmitter MAC Address field, a Sequence Number field indicating a MAC sequence number, a Received Signal Strength Indicator (RSSI) field indicating signal power, a Noise field indicating noise power, a Wi-Fi Class field, an MCS index field by Wi-Fi Class, and a field indicating the Number of Spatial Streams.

[0195] According to one embodiment, the required performance may include at least one of a bit rate, codec latency, and PER (packet error rate).

[0196] According to one embodiment, the framework data may include audio data to be transmitted to the sink device. The framework data may further include at least one of a D2D Retransmission Count field, a Tx Timestamp field, an Rx Timestamp field, an Audio Channel field, a Frame Type field, a Frame Size field, a Frame Count field, a Packet Count field, a Packet Length field, and a Packet Data field.

[0197] FIG. 15 shows the configuration of a sink device according to one embodiment of the present disclosure.

[0198] The sink device of FIG. 15 may be implemented as the sink device shown in FIG. 1 to FIG. 13, or as an audio device operating as a sink device.

[0199] Referring to FIG. 15, the sink device may include a processor (1501), a transceiver (1503), and a memory (1505). In the present disclosure, the processor (1501) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The processor (1501) may also be referred to as a control unit or a controller.

[0200] The processor (1501) can control the overall operation of the sink device described in the embodiments proposed in this disclosure. Specifically, the processor (1501) can control the operation of any one of the sink devices, BIS sink devices, and CIS sink devices shown in FIGS. 1 to 10, for example.

[0201] The transceiver (1503) can transmit and receive signals with other electronic devices or source devices. The transceiver (1503) may also be referred to as a transceiver or a transceiver.

[0202] The memory (1505) can store at least one of the information transmitted and received through the transceiver (1503) and the information generated through the processor (1501).

[0203] According to one embodiment, the processor (1501) may receive pilot data from a source device via device-to-device (D2D) communication. According to one embodiment, the processor (1501) may generate a framework performance report (FPR) in the audio service framework of the sink device based on the pilot data. According to one embodiment, the processor (1501) may control the transmission of the FPR to the source device. According to one embodiment, the processor (1501) may receive framework data from the source device via D2D communication to which a link-specific D2D configuration set determined based on the FPR and the required performance for the wireless audio service is applied.

[0204] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0205] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. In a method of operating a source device in a wireless communication system, The operation of transmitting pilot data to a sink device via D2D (device-to-device) communication; The operation of receiving a framework performance report (FPR) generated by the audio service framework of the sink device based on the above pilot data from the sink device; An operation to determine a link-specific D2D configuration set based on the required performance for the above FPR and wireless audio services; and A method characterized by including the operation of transmitting framework data to the sink device via D2D communication by applying the above D2D setting set.

2. In paragraph 1, the above FPR is, A method characterized by including at least one of an ID field indicating an identifier of the sink device, a Frame Count field, a Packet Count field, a Transmission Delay field calculating the transmission delay based on packets successfully received from the source device, a Frame Loss Rate field, a D2D Retransmission Count field indicating the number of data retransmissions of the source device, and a GAP field indicating the difference between the time audio data arrived from the sink device and the actual playback time.

3. In paragraph 1, the above FPR is, It includes a DPR (D2D Performance Report) generated based on the pilot data in the D2D firmware of the above-mentioned sink device, and A method characterized in that the above DPR includes at least one of a Transmitter MAC Address field, a Sequence Number field indicating a MAC sequence number, a Received Signal Strength Indicator (RSSI) field indicating signal power, a Noise field indicating noise power, a Wi-Fi Class field, an MCS index field for each Wi-Fi Class, and a field indicating the Number of Spatial Streams.

4. In paragraph 1, the above required performance is, A method characterized by including at least one of a bit rate, codec latency, and PER (packet error rate).

5. In paragraph 1, the framework data includes audio data to be transmitted to the sink device, and The above framework data is, A method characterized by further including at least one of a D2D Retransmission Count field, a Tx Timestamp field, an Rx Timestamp field, an Audio Channel field, a Frame Type field, a Frame Size field, a Frame Count field, a Packet Count field, a Packet Length field, and a Packet Data field.

6. A method of operating a sink device in a wireless communication system, The operation of receiving pilot data from a source device via D2D (device-to-device) communication; The operation of generating an FPR (framework performance report) in the audio service framework of the sink device based on the above pilot data; The operation of transmitting the above FPR to the source device; and A method characterized by including the operation of receiving framework data from the source device through D2D communication to which a link-specific D2D configuration set determined based on the required performance for the above FPR and wireless audio service is applied.

7. In Paragraph 6, the above FPR is, A method characterized by including at least one of an ID field indicating an identifier of the sink device, a Frame Count field, a Packet Count field, a Transmission Delay field calculating the transmission delay based on packets successfully received from the source device, a Frame Loss Rate field, a D2D Retransmission Count field indicating the number of data retransmissions of the source device, and a GAP field indicating the difference between the time audio data arrived from the sink device and the actual playback time.

8. In Paragraph 6, The operation of generating a DPR (D2D Performance Report) based on the pilot data in the D2D firmware of the sink device further includes A method characterized in that the above DPR includes at least one of a Transmitter MAC Address field, a Sequence Number field indicating a MAC sequence number, a Received Signal Strength Indicator (RSSI) field indicating signal power, a Noise field indicating noise power, a Wi-Fi Class field, an MCS index field for each Wi-Fi Class, and a field indicating the Number of Spatial Streams.

9. In Paragraph 6, the above required performance is, A method characterized by including at least one of a bit rate, codec latency, and PER (packet error rate).

10. In paragraph 6, the framework data includes audio data to be transmitted to the sink device, and The above framework data is, A method characterized by further including at least one of a D2D Retransmission Count field, a Tx Timestamp field, an Rx Timestamp field, an Audio Channel field, a Frame Type field, a Frame Size field, a Frame Count field, a Packet Count field, a Packet Length field, and a Packet Data field.

11. In a source device in a wireless communication system, Transmitter / receiver; and It includes a control unit, and the control unit, Controls the transmission of pilot data to the sink device via D2D (device-to-device) communication, and Based on the above pilot data, an FPR (framework performance report) generated by the audio service framework of the sink device is received from the sink device, and Based on the required performance for the above FPR and wireless audio services, a link-specific D2D configuration set is determined, and A device characterized by controlling the transmission of framework data to the sink device via D2D communication by applying the above D2D setting set.

12. In Clause 11, the above FPR is, A device characterized by comprising at least one of an ID field indicating an identifier of the sink device, a Frame Count field, a Packet Count field, a Transmission Delay field calculating the transmission delay based on packets successfully received from the source device, a Frame Loss Rate field, a D2D Retransmission Count field indicating the number of data retransmissions of the source device, and a GAP field indicating the difference between the time audio data arrived from the sink device and the actual playback time.

13. In Clause 11, the above FPR is, It includes a DPR (D2D Performance Report) generated based on the pilot data in the D2D firmware of the above-mentioned sink device, and The device is characterized by the fact that the above DPR includes at least one of a Transmitter MAC Address field, a Sequence Number field indicating a MAC sequence number, a Received Signal Strength Indicator (RSSI) field indicating signal power, a Noise field indicating noise power, a Wi-Fi Class field, a Wi-Fi Class MCS index field, and a field indicating the Number of Spatial Streams.

14. In Clause 11, the above required performance is, A device characterized by including at least one of a bit rate, codec latency, and PER (packet error rate).

15. In a sink device in a wireless communication system, Transmitter / receiver; and It includes a control unit, and the control unit, Pilot data is received from a source device via D2D (device-to-device) communication, and Based on the above pilot data, the audio service framework of the sink device generates a framework performance report (FPR), and Control to transmit the above FPR to the source device, and A device characterized by receiving framework data from the source device through D2D communication to which a link-specific D2D configuration set determined based on the required performance for the above FPR and wireless audio service is applied.

Images