WO2019125012A1 - 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치 - Google Patents

무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치 Download PDF

Info

Publication number
WO2019125012A1
WO2019125012A1 PCT/KR2018/016349 KR2018016349W WO2019125012A1 WO 2019125012 A1 WO2019125012 A1 WO 2019125012A1 KR 2018016349 W KR2018016349 W KR 2018016349W WO 2019125012 A1 WO2019125012 A1 WO 2019125012A1
Authority
WO
WIPO (PCT)
Prior art keywords
wireless device
wfd
information
voice data
message
Prior art date
Application number
PCT/KR2018/016349
Other languages
English (en)
French (fr)
Inventor
박기원
이병주
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2019125012A1 publication Critical patent/WO2019125012A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications

Definitions

  • the present invention relates to wireless communication, and more particularly, to a method for performing wireless communication based on voice data in a wireless LAN system and a wireless device using the method.
  • Wireless display transmission technology is a technology that allows a video of a mobile device to be viewed on a large screen television or monitor.
  • Wireless display transmission technology can be roughly divided into content transmission method and mirroring method (i.e., screen casting).
  • the content transmission method is a method of converting a screen of a mobile device into a signal and transmitting the converted signal to a remote device.
  • the mirroring method is a method of simultaneously displaying the image of the mobile device to the remote device by streaming the content file to the remote device.
  • the mirroring method is advantageous in that pixel information of the original screen can be wirelessly transmitted without being dependent on a specific service.
  • Miracast is a wireless video transmission standard created by the WiFi Alliance and can be understood as a wireless display transmission technology. Miracast can also be understood as one type that follows the mirroring scheme.
  • WLAN wireless local area network
  • the method for performing wireless communication based on voice data in a wireless local area network (WLAN) system is characterized in that a first wireless device transmits a first message requesting capability information on the interpretation of voice data of a user to a second wireless Transmitting to the device; The first wireless device receiving a second message including capability information in response to the first message; Determining whether the first wireless device interprets the voice data based on the capability information; The first wireless device transmitting a third message to the second wireless device, the third message including the determination-based role information; And the first wireless device performing data processing for screen mirroring with the second wireless device based on the role information.
  • WLAN wireless local area network
  • a method for performing wireless communication based on voice data in a wireless local area network (WLAN) system with increased convenience for a user and a wireless device using the method can be provided.
  • WLAN wireless local area network
  • 1 is an exemplary diagram showing the structure of an IEEE 802.11 system.
  • FIG. 2 is an exemplary block diagram illustrating a WFD network.
  • FIG. 3 is an exemplary conceptual diagram showing a WFD session.
  • FIG. 4 is a conceptual diagram illustrating a WFD session establishment method.
  • FIG. 5 is a conceptual diagram showing a network between a WFD source and a WFD sink.
  • FIG. 6 is a conceptual diagram showing a procedure for negotiating a WFD capability exchange.
  • FIG. 7 is a conceptual diagram showing a procedure for establishing a WFD session.
  • FIG. 8 is a flowchart for supporting screen mirroring based on voice commands in the wireless LAN system according to the present embodiment.
  • FIG. 9 is a flowchart for supporting screen mirroring based on voice commands in a wireless LAN system according to another embodiment of the present invention.
  • FIG. 10 is a flowchart for determining a subject to interpret speech commands in the wireless LAN system according to the present embodiment.
  • FIG. 11 is a flowchart illustrating a method for performing wireless communication based on voice data in a wireless LAN system according to the present embodiment.
  • FIG. 14 is a block diagram illustrating a wireless device to which the present embodiment is applicable.
  • 15 is a block diagram showing an example of a device included in the processor.
  • 1 is an exemplary diagram showing the structure of an IEEE 802.11 system.
  • an IEEE 802.11 architecture may be composed of a plurality of components, and a wireless LAN system supporting STA mobility transparent to an upper layer by interaction of the wireless LAN system area network, hereinafter " WLAN ") may be provided.
  • a Basic Service Set may be a basic building block of an IEEE 802.11 LAN.
  • BSS Basic Service Set
  • BSS1 and BSS2 there are two BSSs (BSS1 and BSS2), and each BSS may include two STAs.
  • STA1 and STA2 may be included in BSS1
  • STA3 and STA4 may be included in BSS2.
  • the STA refers to a device operating in accordance with the MAC (Medium Access Control) / PHY (Physical) specification of IEEE 802.11.
  • a station may include an Access Point (AP) STA (simply AP) and a non-AP STA.
  • An AP corresponds to a device that provides a network (e.g., WLAN) connection to a non-AP STA via the air interface.
  • a station may be referred to as various names such as (wireless LAN) devices.
  • the APs may be of a fixed or mobile type and may include portable wireless devices (e.g., laptop computers, smart phones, etc.) that provide hot-spots.
  • AP is used in other wireless communication fields such as a base station (BS), a node-B, an evolved Node-B (eNB), a base transceiver system (BTS) (Femto BS) or the like.
  • BS base station
  • eNB evolved Node-B
  • BTS base transceiver system
  • Femto BS Fremto BS
  • Non-AP STAs correspond to devices typically handled by the user, such as laptop computers, PDAs, wireless modems, and smartphones.
  • the non-AP STA includes a terminal, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal, A mobile subscriber station (MSS), and the like.
  • WTRU wireless transmit / receive unit
  • UE user equipment
  • MS mobile station
  • MSS mobile terminal
  • MSS mobile subscriber station
  • an ellipse representing a BSS can be understood as indicating a coverage area in which STAs included in each BSS maintain communication. This area can be referred to as a BSA (Basic Service Area).
  • BSA Basic Service Area
  • the most basic type of BSS in an IEEE 802.11 LAN is an independent BSS (IBSS).
  • an IBSS may have a minimal form consisting of only two STAs.
  • the BSS (BSS1 or BSS2) of Fig. 1 is the simplest form and can be understood as a representative example of the IBSS. This configuration is possible when STAs can communicate directly.
  • this type of LAN can be configured in a case where a LAN is required instead of being configured in advance. This type of LAN may also be referred to as an ad-hoc network.
  • an operation between an apparatus i.e., AP and STA in an infrastructure BSS (basic service set) in which an access point (AP) functions as a hub is mainly defined.
  • the AP may be responsible for physical layer support for wireless / wired connections, routing capabilities for devices on the network, ability to add / remove devices to the network, and service provisioning capabilities. That is, in a conventional wireless LAN system, devices in a network are connected through an AP and are not directly connected to each other.
  • Wi-Fi Direct standard is defined as a technology for supporting direct connection between devices.
  • WiFi Direct is a direct communication technology that allows devices (or STAs (stations)) to easily connect with each other without an access point that is basically required in existing WLAN systems.
  • WFD WiFi Direct
  • WFD WiFi direct
  • a connection between the devices can be established without complicated setup process to provide various services to the user.
  • Wi-Fi P2P WiFi Direct
  • Wi-Fi P2P Wi-Fi P2P
  • Wi-Fi P2P Wi-Fi P2P
  • P2P group owner hereinafter referred to as 'P2P GO'
  • P2P group owner hereinafter referred to as 'P2P GO'
  • P2P clients can exist around P2P GO. Only one P2P GO can exist in one P2P group, and all the other devices are client devices.
  • Wi-Fi Direct links eg, Send, Play, Display, Print, etc.
  • WFA Wi-Fi Alliance
  • WFDS Wi-Fi Direct Service
  • an application can be controlled or managed by an application service platform ("ASP").
  • WFDS devices supported by WFDS may include devices supporting a wireless LAN system such as a display device, a printer, a digital camera, a projector, and a smart phone.
  • the WFDS device may also include an STA and an AP.
  • WFDS devices within a WFDS network can be directly connected to each other.
  • the WFD standard is defined for transmitting audio / video (AV) data between devices while satisfying high quality and low latency.
  • Wi-Fi devices are connected to each other in a peer-to-peer (P2P) manner without going through a home network, an office network, or a hot- .
  • P2P peer-to-peer
  • WFD devices in the WFD network may discover information about the WFD device (e.g., capability information), render a WFD session, and then render the content through a WFD session.
  • information about the WFD device e.g., capability information
  • a WFD session may be a network between a source device providing content and a sink device receiving and rendering the content.
  • the source apparatus can be referred to as a WFD source.
  • the sink device can be referred to as a WFD synchronizer.
  • the WFD source may mirror the data present on the display (or screen) of the WFD source to the display of the WFD sink.
  • the WFD source and the WFD sink may exchange the first sequence message with each other to perform the device search and service search procedure.
  • IP internet protocol
  • RTSP real time streaming protocol
  • 'TCP' transmission control protocol
  • a capability negotiation procedure between the WFD source and the WFD sink may be performed via RTSP.
  • the WFD source and the WFD sink may exchange RTSP-based messages (i.e., M1 to M4) while the capability negotiation procedure is performed.
  • the WFD source and the WFD sink may then exchange WFD session control messages.
  • a data session over RTP can be established between the WFD source and the WFD sink.
  • a User Datagram Protocol may be used for data transport in a WFD network.
  • FIG. 2 is an exemplary block diagram illustrating a WFD network.
  • a WFD source 200 and a WFD sink 250 may be connected as a WFD device based on a specific connection technique (e.g., a WiFi-P2P technique).
  • a specific connection technique e.g., a WiFi-P2P technique.
  • the WFD source 200 of FIG. 2 may be a device that supports streaming of multimedia content over a P2P link.
  • the WFD sink 250 may be a device that performs a procedure (i.e., performs a rendering procedure) to generate an image and / or sound based on multimedia content received from the WFD source 200 over a P2P link have.
  • the WFD sink 250 of FIG. 2 may be a primary sink or a secondary sink.
  • the secondary sink may render only the audio payload from the WFD source 200.
  • FIG. 3 is an exemplary conceptual diagram showing a WFD session.
  • the WFD source 300 of FIG. 3 may be coupled to a primary sink 305 or a secondary sink 310 based on an audio-only session.
  • the WFD source 320 may be coupled to a primary sink 325 based on a video-only session.
  • the WFD source 340 may be coupled to a primary sink 345 based on an audio and video session.
  • the primary sink 365 may render video and the secondary sink 370 may render audio.
  • the primary sink 365 may render both video and audio.
  • the WFD sessions of various schemes shown in FIG. 3 may be established after performing the procedure to be described with reference to FIG.
  • FIG. 4 is a conceptual diagram illustrating a WFD session establishment method.
  • a WFD Device Discovery S401
  • a WFD Service Discovery S402
  • a WFD Connection Setup S403
  • a Capability Exchange and Negotiation S404
  • the WFD source may perform a WFD device search procedure to find a peer device (i.e., a WFD sink) for the WFD.
  • a peer device i.e., a WFD sink
  • a beacon frame, a probe request frame, and a probe response frame transmitted by a WFD source and a WFD sink for a WFD device search procedure may include a WFD information element (IE).
  • the WFD IE may include information associated with a WFD, such as a device type or device state.
  • the WFD source may transmit a probe request frame containing the WFD IE to the WFD Sync.
  • the WFD sink may send a probe response frame containing the WFD IE in response to the probe request frame.
  • the probe request frame may include both the WFD IE and P2P information elements.
  • the probe response frame which is a response to the probe request frame, may be transmitted on the same channel as the received probe request frame.
  • the probe response frame may include both P2P IE and WFD IE.
  • a search can be performed for the service capability between the WFD source and the WFD sink that performed the WFD device search.
  • the WFD service discovery procedure may be an optional procedure.
  • the WFD sink transmits a service search response frame including information on the WFD capability in response to the service search request frame .
  • the WFD device may select a WFD device (e.g., WFD sink) for WFD connection setup.
  • a WFD device e.g., WFD sync
  • WFD connection setup may be selected based on policy or user input.
  • Specific connection techniques e.g., Wi-Fi P2P or Tunneled Direct Link Setup, hereinafter referred to as TDLS
  • TDLS Tunneled Direct Link Setup
  • the WFD device may use a connectivity scheme based on the preferred connectivity information and an associated basic service set identifier subelement carried by the WFD Information Element (WFD IE). You can decide.
  • WFD IE WFD Information Element
  • step S404 of FIG. 4 a capability exchange procedure and a negotiation procedure may be performed between the WFD source and the WFD sink. Step S404 will be described in more detail with reference to FIG. 6 to be described later.
  • FIG. 5 is a conceptual diagram showing a network between a WFD source and a WFD sink.
  • the WFD source 500 may be coupled to a WFD sink 510 based on a Wi-Fi P2P link.
  • the WFD source 500 and the WFD sink 510 may be combined with the same AP.
  • the WFD source 500 and the WFD sink 510 may be combined with different APs.
  • the WFD source 500 and the WFD sink 510 may not be coupled to separate APs.
  • the source 550 may be coupled to the WFD sink 560 based on the TDLS link. For example, when a WFD connection is performed using a TDLS link, the WFD source 550 must maintain a connection with the WFD source 550 and the associated AP. In addition, when a WFD connection is performed using a TDLS link, the WFD sink 560 must maintain a connection with the WFD sink 560 and the associated AP. In this case, the AP for which the WFD source 550 maintains a connection and the AP for which the WFD sink 560 maintains a connection may be the same.
  • Wi-Fi direct i.e., P2P
  • TDLS link is used between a WFD source and a WFD sink, but the present disclosure is not limited thereto.
  • the WFD capability exchange and negotiation procedures may be performed after the WFD connection setup procedure between the WFD devices.
  • the WFD source and the WFD sink can mutually exchange at least one of codecs supported by each other, profile information of a codec, level information of a codec, and resolution information.
  • WFD capability exchange and negotiation can be performed by exchanging messages using RTSP (Real Time Streaming Protocol). Also, during the WFD session, a set of parameters for defining the audio / video payload can be determined. Specifically, as shown in FIG. 6 to be described later, the WFD capability exchange and negotiation procedures can be performed by exchanging RTSP M4 messages from RTSP M1.
  • RTSP Real Time Streaming Protocol
  • FIG. 6 is a conceptual diagram showing a procedure for WFD capability negotiation.
  • FIG. 6 illustrates the assumption that the L3 connectivity has been successfully completed after the procedure described above with reference to FIG. 4 has been performed. That is, one IP address can be allocated for the WFD source and the WFD sink in FIG.
  • the WFD source may send an RTSP M1 request message to initiate the RSTP procedure and the WFD capability negotiation.
  • the RTSP M1 request message may include an RTSP OPTIONS Request.
  • the WFD sink may transmit an RTSP M1 response message enumerating its supported RTSP method.
  • the RTSP M1 response message may include an RTSP OPTIONS Response.
  • the WFD sink may send an RTSP M2 request message to determine the set of RTSP methods supported by the WFD source.
  • the RTSP M2 request message may include an RTSP OPTIONS Request.
  • the WFD source may respond with an RTSP M2 response message enumerating the RTSP method it supports.
  • the RTSP M2 response message may include an RTSP OPTIONS Response.
  • the WFD source may send an RTSP M3 request message to query the attributes of the WFD sink and the capabilities of the WFD sink.
  • the RTSP M3 request message may include an RTSP GET_PARAMETER Request.
  • the RTSP M3 request message may explicitly specify a list of capabilities of the WFD sink that the WFD source wishes to acquire from the WFD sink.
  • the WFD sink may respond with an RTSP M3 response message.
  • the RTSP M3 response message may include an RTSP GET_PARAMETER Response.
  • the RTSP M3 response message may include the values of the parameters of the requested WFD sink in accordance with the RTSP M3 request message.
  • the WFD source may determine an optimal set of parameters to be used during the WFD session based on the RTSP M3 response message.
  • the WFD source may send an RTSP M4 request message containing the determined parameter set to the WFD Sync.
  • the RTSP M4 request message may include an RTSP SET_PARAMETER Request.
  • the WFD sink may respond with an RTSP M4 response message.
  • the RTSP M4 response message may include an RTSP SET_PARAMETER Response.
  • FIG. 7 is a conceptual diagram showing a procedure for establishing a WFD session. Referring to FIGS. 1 to 7, FIG. 7 is described on the assumption that steps S601 to S608 are performed in advance.
  • the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD Sync.
  • RTSP M5 Trigger SETUP request RTSP M5 Trigger SETUP request
  • the WFD sink may send an RTSP M5 response message to the WFD source in response to the RTSP SET parameter request message.
  • step S703 if the RTSP M5 message including the trigger parameter setting (SETUP) is successfully exchanged, the WFD sink may transmit an RTSP SETUP request message (RTSP M6 request) to the WFD source.
  • RTSP M6 request RTSP SETUP request message
  • the WFD source may transmit an RTSP SETUP response message (RTSP M6 response) to the WFD synchronizer.
  • RTSP M6 response For example, successful establishment of an RTSP session may be indicated through the setting of the status code contained in the RTSP ⁇ 6 response message.
  • step S705 after a successful exchange of the RTSP M6 message, the WFD sink may send an RTSP M7 request message to the WFD source to indicate that it is ready to receive the RTP stream.
  • the WFD source may transmit an RTSP PLAY response message to the WFD Sync.
  • successful establishment of a WFD session may be indicated based on the status code included in the RTSP PLAY response message.
  • the WFD source After the WFD session is established, the WFD source includes an RTSP M3 request message (RTSP GET_PARAMETER request message) to acquire capability for at least one RTSP parameter supported by the WFD Sync with WFD Sync, an Audio / Video An RTSP M4 request message for setting at least one RTSP parameter value corresponding to a WFD session for capacity renegotiation between the WFD source and the WFD sink, an RTSP M4 request message for triggering the WFD sink to transmit an RTSP PAUSE request message (RTSP M9 request message) An RTSP M12 request message to indicate that the WFD source enters WFD standby mode, an input type to be used in a user input back channel (UIBC), an RTSP M14 request message to select an input device and other parameters Or an RTSP M15 request message for enabling or disabling the user input back channel (UIBC) to the WFD Sync .
  • RTSP M3 request message RTSP GET_PARAMETER request
  • the WFD sink receiving the RTSP request message from the WFD source may respond with an RTSP response message.
  • the WFD Sync includes an RTSP M7 request message (RTSP PLAY request message) for starting (or resuming) audio / video streaming, an RTSP M9 request message for suspending audio / video streaming sent from the WFD source to the WFD Sync
  • An RTSP M10 request message to request the WFD source to change the audio rendering device
  • an RTSP M11 request message to direct the change of the active connector type (active connector type)
  • a WFD sink to WFD standby mode
  • An M13 request message requesting the WFD source to refresh an instantaneous decoding refresh (IDR), an input type to be used in the UIBC, an RTSP M14 request message for selecting input devices and other parameters, or an activation of the UIBC (RTSP M15 request message for enable or disable) to the WFD source .
  • IDR instantaneous decoding refresh
  • the WFD source receiving the above-listed RTSP request message from the WFD sink may respond with an RTSP response message.
  • the WFD source and the WFD sink may proceed with audio / video streaming using codecs that are commonly supported by both.
  • codecs that are commonly supported by both.
  • FIG. 8 is a flowchart for supporting screen mirroring based on voice commands in the wireless LAN system according to the present embodiment.
  • FIG. 8 is described on the assumption that the voice command of the user is interpreted in the WFD sink device 820.
  • FIG. 8 is described on the assumption that the voice command of the user is interpreted in the WFD sink device 820.
  • the WFD sink device 820 may receive a voice command from the user.
  • the voice command may be voice data of the user.
  • the voice data may be raw data requesting execution of a specific application of the WFD source device.
  • the row data may be a voice command of the user such as " Kakao Talk Execute ".
  • the WFD sink device 820 may interpret the voice command of the user. For example, the WFD sink device 820 may interpret a user's voice command as an instruction.
  • the WFD sink device 820 may send an RTSP M30 request message to the WFD source device 810 to control the application of the WFD source device 810.
  • the RTSP M30 request message may include the command interpreted in step S820.
  • the RTSP M30 request message may include an identification field and a control field.
  • the identification field may include application ID information (e.g., " com.kakao.talk ") for identifying a particular application of the WFD source device 810.
  • application ID information e.g., " com.kakao.talk "
  • the application ID information may be referred to as an application package name.
  • control field may contain control parameter information of 3 bits in length.
  • the WFD source device 810 receiving the RTSP M30 request message may execute the application identified by the identification field.
  • the WFD source device 810 receiving the RTSP M30 request message may terminate the application identified by the identification field.
  • a value corresponding to '2' to '7' for the control field may be reserved.
  • step S840 the WFD source device 810 may execute a specific application based on the RTSP M30 request message.
  • the application ID information and the control parameter information may be transferred to an internal module (e.g., Framework) responsible for executing an application installed in the WFD source device 810. [ .
  • an internal module e.g., Framework
  • the WFD source device 810 may send an RTSP M30 response message to the WFD sink device 820 in response to the RTSP M30 request message.
  • the RTSP M30 response message may include ACK information to inform successful reception of the RTSP M30 request message.
  • the WFD source device 810 may send a data stream for a particular application in accordance with the RTSP M30 request message to the WFD sink device 820.
  • a data stream for a particular application may be transmitted via a WFD session established beforehand between the WFD source device 810 and the WFD sink device 820.
  • FIG. 9 is a flowchart for supporting screen mirroring based on voice commands in a wireless LAN system according to another embodiment of the present invention.
  • FIG. 9 is described on the assumption that the voice command of the user is interpreted in the WFD source apparatus 910.
  • FIG. 9 is described on the assumption that the voice command of the user is interpreted in the WFD source apparatus 910.
  • the WFD sink device 920 may receive a voice command from the user.
  • the voice command may be voice data of the user.
  • the voice data may be raw data requesting execution of a specific application of the WFD source device.
  • the row data may be a voice command of the user such as " Kakao Talk Execute ".
  • step S920 the WFD sink device 920 may send an RTSP M31 request message to the WFD source device 910, including raw data associated with the user's voice command.
  • the WFD source device 910 may send an RTSP M31 response message to the WFD sink device 920 in response to the RTSP M31 request message.
  • the RTSP M31 response message may include ACK information for informing the successful reception of the RTSP M31 request message.
  • the WFD source device 910 may interpret the voice command of the user included in the RTSP M31 request message. For example, the WFD source device 910 may interpret a user's voice command as an instruction.
  • the command interpreted in step S940 may include application ID information (e.g., " com.kakao.talk ") for identifying a particular application of the WFD source device 910 and control of the operation of the WFD source device 910 And may include control parameter information.
  • application ID information e.g., " com.kakao.talk "
  • the application ID information may be referred to as an application package name.
  • control parameter information may be implemented to have a 3-bit length.
  • the WFD source device 910 can execute the application identified by the application ID information.
  • the WFD source device 910 can terminate the application identified by the application ID information.
  • a value corresponding to '2' to '7' for the control parameter information can be reserved.
  • step S950 the WFD source device 910 may execute a specific application based on the interpreted instruction.
  • the application ID information and the control parameter information may be transferred to an internal module (e.g., Framework) responsible for executing an application installed in the WFD source device 910.
  • an internal module e.g., Framework
  • step S960 in order to perform the screen mirroring, the WFD source device 910 may transmit a data stream for a specific application according to the interpreted command to the WFD sink device 920.
  • a data stream for a particular application may be sent via a pre-established WFD session between the WFD source device 910 and the WFD sink device 920.
  • FIG. 10 is a flowchart for determining a subject to interpret speech commands in the wireless LAN system according to the present embodiment.
  • the WFD source device 1010 may transmit an RTSP M3 request message including an RTSP GET_PARAMETER request to the WFD sink device 1020.
  • FIG. 1 A block diagram illustrating an RTSP M3 request message including an RTSP GET_PARAMETER request.
  • the RTSP M3 request message of FIG. 10 may further include parameter information (e.g., wfd_voice_command_capability) for requesting capability information on the interpretation of the user's voice data in the RTSP M3 request message of FIG.
  • parameter information e.g., wfd_voice_command_capability
  • the WFD source device 1010 may receive an RTSP M3 response message including an RTSP GET_PARAMETER response in response to the RTSP M3 request message.
  • the RTSP M3 response message of FIG. 10 may further include capability information (e.g., wfd_voice_command_capability) regarding the interpretation of the user's voice data in the RTSP M3 response message of FIG.
  • capability information e.g., wfd_voice_command_capability
  • the capability information (e.g., wfd_voice_command_capability) may be 1-bit information.
  • capability information e.g., wfd_voice_command_capability
  • wfd_voice_command_capability may be set to '0' if the WFD sink device 1020 does not support the interpretation of the user's voice data.
  • capability information e.g., wfd_voice_command_capability
  • WFD sink device 1020 supports the interpretation of the user's voice data.
  • the WFD source apparatus 1010 can determine the subject of analyzing the user's voice data based on the capability information.
  • the WFD source device 1010 may determine that the WFD sink device 1020 is the subject that interprets the voice data.
  • the WFD source device 1010 may determine that it is the subject that interprets the voice data.
  • the WFD source device 1010 may send an RTSP M4 request message containing an RTSP SET_PARAMETER Request to the WFD sink device 920.
  • the RTSP M4 request message of FIG. 10 may further include role information (e.g., wfd_voice_command_role) associated with a subject that interprets voice data in the RTSP M4 request message of FIG.
  • role information e.g., wfd_voice_command_role
  • the role information (e.g., wfd_voice_command_role) may be 1-bit information.
  • the role information e.g., wfd_voice_command_role
  • the role information may be set to '0'.
  • the role information e.g., wfd_voice_command_role
  • the role information may be set to '1'.
  • the WFD source device 1010 may receive an RTSP M4 response message including an RTSP SET_PARAMETER response in response to the RTSP M4 request message.
  • the RTSP M4 response message may include acknowledgment information for the RTSP M4 request message.
  • the procedure may proceed to FIG.
  • FIG. 11 is a flowchart illustrating a method for performing wireless communication based on voice data in a wireless LAN system according to the present embodiment.
  • the first wireless device of Fig. 11 corresponds to a WFD source device
  • the second wireless device of Fig. 11 may correspond to a WFD sink device.
  • the first wireless device may transmit a first message to the second wireless device requesting capability information regarding the interpretation of the user's voice data.
  • the first message of FIG. 11 can be understood as the RTSP M3 request message of FIGS. 6 and 10.
  • FIG. 11 the first message of FIG. 11 can be understood as the RTSP M3 request message of FIGS. 6 and 10.
  • the first wireless device may receive a second message including capability information of the second wireless device in response to the first message.
  • the second message of FIG. 11 can be understood as the RTSP M3 response message of FIGS. 6 and 10.
  • the capability information e.g., wfd_voice_command_capability
  • the capability information may be 1-bit information.
  • the first wireless device may know that the second wireless device does not support interpretation of the user's voice data.
  • capability information e.g., wfd_voice_command_capability
  • the first wireless device may know that the second wireless device supports interpretation of the user's voice data.
  • capability information e.g., wfd_voice_command_capability
  • the first wireless device can determine the subject that interprets the user's voice data based on the capability information.
  • the first wireless device may determine the second wireless device as the subject to interpret the voice data.
  • the first wireless device can determine the subject as the subject to interpret the voice data.
  • the first wireless device may transmit a third message including role information based on the determination of step S1130 to the second wireless device.
  • the role information (e.g., wfd_voice_command_role) may be 1-bit information.
  • the role information e.g., wfd_voice_command_role
  • the role information may be set to '0'.
  • the role information e.g., wfd_voice_command_role
  • the role information may be set to '1'.
  • the first wireless device may perform data processing for screen mirroring with the second wireless device based on the role information.
  • the first wireless device may receive the fourth message from the second wireless device, as shown in FIG.
  • the fourth message of FIG. 11 may correspond to the RTSP M30 request message of FIG.
  • the fourth message includes first information for identifying an application to be executed by the first wireless device (i.e., information contained in the identification field of FIG. 8), and second information for controlling the operation of the application Information included in the control field of FIG. 8).
  • the first wireless device may transmit a data stream relating to the application to the second wireless device based on the first information and the second information.
  • the first wireless device may receive the fourth message from the second wireless device, as shown in FIG.
  • the fourth message of FIG. 11 may correspond to the RTSP M31 request message of FIG. As an example, it may include raw data relating to the user's voice data.
  • the first wireless device may also generate analysis information for an application to be executed by the first wireless device based on the received raw data.
  • the analysis information includes application ID information (e.g., " com.kakao.talk ") for identifying a specific application of the first wireless device and control parameter information for controlling the operation of the first wireless device .
  • application ID information e.g., " com.kakao.talk "
  • the first wireless device may transmit a data stream for the application to the second wireless device based on the analysis information.
  • wireless communication with enhanced convenience can be performed from the user's point of view.
  • FIGS. 12 and 13 are flowcharts for supporting screen mirroring based on UIBC (User Input Back Channel) according to another embodiment of the present invention.
  • UIBC User Input Back Channel
  • the wfd_uibc_capability parameter included in the RTSP M3 Response message of FIG. 6 may be defined as shown in Table 1 below.
  • the WFD sink device of Fig. 12 When the WFD sink device of Fig. 12 receives speech raw data (e.g., " execute kakao talk ") from the user, the WFD sink device can interpret the speech raw data as an instruction word (e.g., "
  • the command interpreted at the WFD sink device can be included in the UIBC input message and delivered to the WFD source device.
  • a UIBC Input message (HIDC input format) may include an identification field and a control field.
  • the identification field may include application ID information (e.g., " com.kakao.talk ") for identifying a particular application of the WFD source device.
  • application ID information e.g., " com.kakao.talk "
  • the application ID information may be referred to as an application package name.
  • control field may contain control parameter information of 3 bits in length.
  • the WFD source device receiving the UIBC Input message can execute the application identified by the identification field.
  • the WFD source device receiving the UIBC Input message may terminate the application identified by the identification field.
  • a value corresponding to '2' to '7' for the control field may be reserved.
  • the WFD sink device that has completed the UIBC capability negotiation and the WFD session setup can receive voice raw data (e.g., " execute a kakao chat call ") from the user.
  • voice raw data e.g., " execute a kakao chat call "
  • the WFD sink device can transmit voice raw data to the WFD source device through the UIBC Input message.
  • the WFD source device can be interpreted as an instruction that can execute the received voice raw data (eg, "and control value: execution, termination).
  • the WFD source device can then execute the interpreted instruction.
  • FIG. 14 is a block diagram illustrating a wireless device to which the present embodiment is applicable.
  • a wireless device is an STA capable of implementing the above-described embodiment, and can operate as an AP or a non-AP STA. Further, the wireless device may correspond to the above-mentioned user or to a transmitting terminal that transmits a signal to the user.
  • processor 14 includes a processor 1410, a memory 1420 and a transceiver 1430 as shown.
  • the illustrated processor 1410, memory 1420 and transceiver 1430 may each be implemented as separate chips, or at least two blocks / functions may be implemented on a single chip.
  • a transceiver 1430 is a device that includes a transmitter and a receiver and is capable of performing only the operation of either the transmitter or the receiver when a particular operation is performed or the operation of both the transmitter and the receiver have.
  • Transceiver 1430 may include one or more antennas for transmitting and / or receiving wireless signals.
  • the transceiver 1430 may also include an amplifier for amplifying the received signal and / or the transmitted signal and a bandpass filter for transmitting on a specific frequency band.
  • Processor 1410 may implement the functions, processes, and / or methods suggested herein. For example, the processor 1410 may perform the operations according to the embodiment described above. That is, processor 1410 may perform the operations described in the embodiments of FIGS. 1-12.
  • the processor 1410 may include an application-specific integrated circuit (ASIC), another chipset, logic circuitry, a data processing device, and / or a transducer for converting baseband signals and radio signals.
  • ASIC application-specific integrated circuit
  • Memory 1420 can include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.
  • ROM read-only memory
  • RAM random access memory
  • flash memory volatile and non-volatile memory
  • 15 is a block diagram showing an example of a device included in the processor.
  • FIG. 15 For convenience of explanation, the example of FIG. 15 is described with reference to a block for a transmission signal, but it is obvious that a received signal can be processed using the block.
  • the illustrated data processing unit 1510 generates transmission data (control data and / or user data) corresponding to a transmission signal.
  • the output of the data processing unit 1510 may be input to the encoder 1520.
  • the encoder 1520 can perform coding through BCC (binary convolutional code) or LDPC (low-density parity-check) techniques. At least one encoder 1520 may be included and the number of encoders 1520 may be determined according to various information (e.g., the number of data streams).
  • the output of the encoder 1520 may be input to an interleaver 1530.
  • Interleaver 1530 performs an operation of spreading successive bit signals over radio resources (e.g., time and / or frequency) to prevent burst errors due to fading or the like.
  • Radio resources e.g., time and / or frequency
  • At least one interleaver 1530 may be included, and the number of interleavers 1530 may be determined according to various information (e.g., the number of spatial streams).
  • the output of the interleaver 1530 may be input to a constellation mapper 1540.
  • the constellation mapper 1540 performs constellation mapping such as biphase shift keying (BPSK), quadrature phase shift keying (QPSK), and quadrature amplitude modulation (n-QAM).
  • BPSK biphase shift keying
  • QPSK quadrature phase shift keying
  • n-QAM quadrature amplitude modulation
  • the output of constellation mapper 1540 may be input to spatial stream encoder 1550.
  • the spatial stream encoder 1550 performs data processing to transmit a transmission signal through at least one spatial stream.
  • the spatial stream encoder 1550 may perform at least one of space-time block coding (STBC), cyclic shift diversity (CSD) insertion, and spatial mapping for a transmission signal.
  • STBC space-time block coding
  • CSS cyclic shift diversity
  • the output of spatial stream encoder 1550 may be input to an IDFT 1560 block.
  • the IDFT 1560 block performs inverse discrete Fourier transform (IDFT) or inverse fast Fourier transform (IFFT).
  • IDFT inverse discrete Fourier transform
  • IFFT inverse fast Fourier transform
  • the output of the IDFT 1560 block is input to the GI (Guard Interval) inserter 1570 and the output of the GI inserter 1570 is input to the transceiver 1430 of FIG.
  • GI Guard Interval

Abstract

본 일 실시 예에 따른 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법은, 제1 무선 장치가, 사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하는 제1 메시지를 제2 무선 장치로 송신하는 단계; 제1 무선 장치가, 제1 메시지에 대한 응답으로 능력 정보를 포함하는 제2 메시지를 수신하는 단계; 제1 무선 장치가, 능력 정보를 기반으로 음성 데이터를 해석하는 주체를 판단하는 단계; 제1 무선 장치가, 판단에 기반한 역할 정보를 포함하는 제3 메시지를 제2 무선 장치로 송신하는 단계; 및 제1 무선 장치가, 역할 정보를 기반으로 제2 무선 장치와 화면 미러링을 위한 데이터 처리를 수행하는 단계를 포함한다.

Description

무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치
본 명세서는 무선 통신에 관한 것으로, 더 상세하게는 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치에 관한 것이다.
무선 디스플레이 전송 기술은 모바일 기기의 영상을 대화면 TV(television) 또는 모니터에서 볼 수 있게 하는 기술이다. 무선 디스플레이 전송 기술은 크게 컨텐츠 전송 방식과 미러링 방식(즉, 스크린 캐스팅)으로 나눠질 수 있다.
콘텐츠 전송 방식은 모바일 기기 화면을 신호로 변환한 후 변환된 신호를 원격 기기로 전송하는 방식이다. 미러링 방식은 컨텐츠 파일을 원격 기기로 스트리밍함으로써 모바일 기기의 영상을 원격 기기에 동시에 보여주는 방식이다. 미러링 방식은 특정 서비스에 종속되지 않고 원래 화면의 픽셀 정보를 그대로 무선으로 전송할 수 있다는 장점이 있다.
미라캐스트(Miracast)는 와이파이 협회(WiFi Alliance)가 만든 무선 영상 전송 규격이자 무선 디스플레이 전송 기술로 이해될 수 있다. 또한, 미라캐스트는 미러링 방식을 따르는 하나의 유형으로 이해될 수 있다.
본 명세서의 목적은 사용자의 편의성이 증대된 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치를 제공하는데 있다.
본 일 실시 예에 따른 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법은, 제1 무선 장치가, 사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하는 제1 메시지를 제2 무선 장치로 송신하는 단계; 제1 무선 장치가, 제1 메시지에 대한 응답으로 능력 정보를 포함하는 제2 메시지를 수신하는 단계; 제1 무선 장치가, 능력 정보를 기반으로 음성 데이터를 해석하는 주체를 판단하는 단계; 제1 무선 장치가, 판단에 기반한 역할 정보를 포함하는 제3 메시지를 제2 무선 장치로 송신하는 단계; 및 제1 무선 장치가, 역할 정보를 기반으로 제2 무선 장치와 화면 미러링을 위한 데이터 처리를 수행하는 단계를 포함한다.
본 명세서의 일 실시 예에 따르면, 사용자의 편의성이 증대된 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치가 제공될 수 있다.
도 1은 IEEE 802.11 시스템의 구조를 나타내는 예시적인 도면이다.
도 2는 WFD 네트워크를 보여주는 예시적인 블록도이다.
도 3은 WFD 세션을 보여주는 예시적인 개념도이다.
도 4는 WFD 세션 설정 방법을 나타낸 개념도이다.
도 5는 WFD 소스와 WFD 싱크 간의 네트워크를 나타낸 개념도이다.
도 6은 WFD 능력 교환 협상을 위한 절차를 보여주는 개념도이다.
도 7은 WFD 세션 확립을 위한 절차를 보여주는 개념도이다.
도 8은 본 일 실시 예에 따른 무선랜 시스템에서 음성 명령을 기반으로 화면 미러링을 지원하기 위한 순서도이다.
도 9는 본 다른 실시 예에 따른 무선랜 시스템에서 음성 명령을 기반으로 화면 미러링을 지원하기 위한 순서도이다.
도 10은 본 일 실시 예에 따른 무선랜 시스템에서 음성 명령의 해석하는 주체를 결정하기 위한 순서도이다.
도 11은 본 일 실시 예에 따른 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법을 보여주는 순서도이다.
도 12 및 도 13은 본 또 다른 실시 예에 따라 UIBC를 기반으로 화면 미러링을 지원하기 위한 순서도이다.
도 14는 본 실시 예가 적용될 수 있는 무선 장치를 나타내는 블록도이다.
도 15는 프로세서에 포함되는 장치의 일례를 나타내는 블록도이다.
전술한 특성 및 이하 상세한 설명은 모두 본 명세서의 설명 및 이해를 돕기 위한 예시적인 사항이다. 즉, 본 명세서는 이와 같은 실시 예에 한정되지 않고 다른 형태로 구체화될 수 있다. 다음 실시 형태들은 단지 본 명세서를 완전히 개시하기 위한 예시이며, 본 명세서가 속하는 기술 분야의 통상의 기술자들에게 본 명세서를 전달하기 위한 설명이다. 따라서, 본 명세서의 구성 요소들을 구현하기 위한 방법이 여럿 있는 경우에는, 이들 방법 중 특정한 것 또는 이와 동일성 있는 것 가운데 어떠한 것으로든 본 명세서의 구현이 가능함을 분명히 할 필요가 있다.
본 명세서에서 어떤 구성이 특정 요소들을 포함한다는 언급이 있는 경우, 또는 어떤 과정이 특정 단계들을 포함한다는 언급이 있는 경우는, 그 외 다른 요소 또는 다른 단계들이 더 포함될 수 있음을 의미한다. 즉, 본 명세서에서 사용되는 용어들은 특정 실시 형태를 설명하기 위한 것일 뿐이고, 본 명세서의 개념을 한정하기 위한 것이 아니다. 나아가, 발명의 이해를 돕기 위해 설명한 예시들은 그것의 상보적인 실시 예도 포함한다.
본 명세서에서 사용되는 용어들은 본 명세서가 속하는 기술 분야의 통상의 기술자들이 일반으로 이해하는 의미를 갖는다. 보편적으로 사용되는 용어들은 본 명세서의 맥락에 따라 일관적인 의미로 해석되어야 한다. 또한, 본 명세서에서 사용되는 용어들은, 그 의미가 명확히 정의된 경우가 아니라면, 지나치게 이상적이거나 형식적인 의미로 해석되지 않아야 한다. 이하 첨부된 도면을 통하여 본 명세서의 실시 예가 설명된다.
도 1은 IEEE 802.11 시스템의 구조를 나타내는 예시적인 도면이다.
도 1을 참조하면, IEEE 802.11 구조는 복수의 구성요소들로 구성될 수 있고, 이들의 상호작용에 의해 상위계층에 대해 트랜스패런트(transparent)한 STA 이동성을 지원하는 무선랜 시스템이(wireless local area network, 이하, 'WLAN')이 제공될 수 있다.
기본 서비스 세트(Basic Service Set, BSS)는 IEEE 802.11 LAN 의 기본 구성 블록일 수 있다. 도 1을 참조하면, 2개의 BSS(BSS1 및 BSS2)가 존재하고, 각 BSS는 2 개의 STA를 포함할 수 있다. 예를 들어, STA1 및 STA2는 BSS1에 포함되고, STA3 및 STA4는 BSS2에 포함될 수 있다.
여기서, STA는 IEEE 802.11의 MAC(Medium Access Control)/PHY(Physical) 규정에 따라 동작하는 기기를 의미한다. 스테이션(STA)는 AP(Access Point) STA(간단히, AP) 및 비-AP(non-AP) STA를 포함할 수 있다. AP는 무선 인터페이스를 통해 비-AP STA에게 네트워크(예, WLAN) 접속을 제공하는 기기에 해당한다. 스테이션은 (무선랜) 장치 등의 다양한 명칭으로 불릴 수 있다.
AP는 고정 형태 또는 이동형태로 구성될 수 있으며, 핫스팟(hot-spot)을 제공하는 휴대용 무선 기기(예, 랩탑 컴퓨터, 스마트 폰 등)를 포함할 수 있다. AP는 다른 무선 통신 분야에서 기지국(Base Station, BS), 노드-B(Node-B), 발전된 노드-B(Evolved Node-B; eNB), 기저 송수신 시스템(Base Transceiver System, BTS), 펨토 기지국(Femto BS) 등에 대응할 수 있다.
비-AP STA는 랩탑 컴퓨터, PDA, 무선 모뎀, 스마트 폰과 같이 일반적으로 사용자가 직접 다루는 기기에 해당한다. 비-AP STA는 단말(terminal), 무선 송수신 유닛(Wireless Transmit/Receive Unit, WTRU), 사용자 장치(User Equipment, UE), 이동국(Mobile Station, MS), 이동 단말(Mobile Terminal), 이동 가입자국(Mobile Subscriber Station, MSS) 등으로 지칭될 수 있다.
도 1을 참조하면, BSS를 나타내는 타원은 각 BSS에 포함된 STA들이 통신을 유지하는 커버리지 영역을 나타내는 것으로 이해될 수 있다. 이 영역을 BSA(Basic Service Area)라고 칭할 수 있다. IEEE 802.11 LAN 에서 가장 기본적인 타입의 BSS는 독립적인 BSS(Independent BSS, IBSS)이다.
예를 들어, IBSS는 2개의 STA만으로 구성된 최소 형태를 가질 수 있다. 또한, 도 1의 BSS(BSS1 또는 BSS2)는 가장 단순한 형태이고, IBSS의 대표적인 예로 이해될 수 있다. 이러한 구성은 STA들이 직접 통신할 수 있는 경우에 가능하다. 또한, 이러한 형태의 LAN은 미리 계획되어서 구성되는 것이 아니라 LAN이 필요한 경우에 구성될 수 있다. 이러한 형태의 LAN은 애드-혹(ad-hoc) 네트워크라고 칭할 수도 있다.
기존의 무선랜 시스템에서는 액세스 포인트(access point, AP)가 허브로서 기능하는 인프라스트럭쳐 (infrastructure) BSS(basic service set) 내에서의 장치(즉, AP 및 STA) 간의 동작이 주로 정의된다.
AP는 무선/유선 연결을 위한 물리 계층 지원 기능, 네트워크 상의 장치들에 대한 라우팅 기능, 장치를 네트워크에 추가/제거하는 기능, 서비스 제공 기능 등을 담당할 수 있다. 즉, 기존의 무선랜 시스템에서는 네트워크 내의 장치들이 AP를 통하여 연결되는 것이지 서로 간에 직접 연결되는 것은 아니다.
장치들 간의 직접 연결을 지원하기 위한 기술로서 와이파이 다이렉트(Wi-Fi Direct, 이하 'WFD') 표준이 정의되고 있다. 와이파이 다이렉트(WFD)는 기존의 무선랜 시스템에서 기본적으로 요구되는 액세스 포인트 없이 장치(device)(또는 STA(station))들 간에 서로 용이하게 연결할 수 있도록 하는 직접 통신 기술이다. 와이파이 다이렉트(WFD)가 사용되는 경우, 복잡한 설정 과정 없이 장치들 간에 연결이 설정되어 사용자에게 다양한 서비스를 제공할 수 있다.
와이파이 다이렉트(WFD)는 와이파이 P2P(이하, 'Wi-Fi P2P')로도 불린다. Wi-Fi P2P는 기존의 Wi-Fi 표준 규격의 대부분의 기능을 유지하면서, 기기 간 직접 통신을 지원하기 위한 부분이 추가된다. 따라서, Wi-Fi 칩(Chip)이 탑재된 기기에 하드웨어 및 물리적 특성을 충분히 활용하고, 주로 소프트웨어 기능 업그레이드만으로 기기 간 P2P 통신을 제공할 수 있는 장점이 있다.
P2P 그룹 내부에서 기존의 인프라스트럭처(infrastructure) 망에서 AP의 역할을 담당하는 장치가 존재하는데 이를 P2P 규격에서는 P2P 그룹 오너(Group Owner, 이하, 'P2P GO')라고 칭한다. P2P GO를 중심으로 다양한 P2P 클라이언트(Client)가 존재할 수 있다. 1개의 P2P 그룹 내에서 P2P GO는 오직 1대만 존재 가능하며, 나머지 장치는 모두 클라이언트 장치가 된다.
와이파이 얼라이언스(Wi-Fi Alliance, 이하, 'WFA')에 의해 Wi-Fi Direct 링크를 이용한 다양한 서비스(예로, 센드(Send), 플레이(Play), 디스플레이(Display), 프린트(Print) 등)을 지원하는 와이파이 다이렉트 서비스(Wi-Fi Direct Service, 이하 'WFDS')가 연구되고 있다. WFDS에 따르면, 애플리케이션은 어플리케이션 서비스 플랫폼(Application Service Platform, 이하 'ASP')에 의해서 제어 또는 관리될 수 있다.
WFDS가 지원하는 WFDS 장치는 디스플레이 장치, 프린터, 디지털 카메라, 프로젝터 및 스마트 폰 등 과 같은 무선랜 시스템을 지원하는 장치들을 포함할 수 있다. 또한, WFDS 장치는 STA 및 AP를 포함할 수 있다. WFDS 네트워크 내의 WFDS 장치들은 서로 직접 연결될 수 있다.
WFD 표준은 높은 품질과 낮은 레이턴시를 만족시키면서 오디오/비디오(AV: audio/video) 데이터를 장치 간에 전송하기 위해 정의된다. WFD 표준이 적용된 WFD 네트워크(WFD 세션)를 통해 Wi-Fi 디바이스들은 홈 네트워크, 오피스 네트워크, 또는 핫-스팟 네트워크에 통하지 않고 피어-투-피어(peer to peer, 이하 'P2P') 방식으로 서로 연결될 수 있다.
이하, WFD 표준에 따라 데이터를 송신 및 수신하는 장치는 WFD 장치라는 용어로 표현될 수 있다. WFD 네트워크 내의 WFD 장치들은 WFD 장치에 대한 정보(예를 들어, 능력 정보(capability information))를 서로 탐색하고, WFD 세션을 설정한 후, WFD 세션을 통해 컨텐츠를 렌더링(rendering) 할 수 있다.
WFD 세션은 컨텐츠를 제공하는 소스 장치(source device) 및 컨텐츠를 수신하고 렌더링하는 싱크 장치(sink device) 간의 네트워크일 수 있다. 본 명세서에서, 소스 장치는 WFD 소스로 언급될 수 있다. 본 명세서에서, 싱크 장치는 WFD 싱크로 언급될 수 있다.
WFD 소스는 WFD 소스의 디스플레이(또는 스크린) 상에 존재하는 데이터를 WFD 싱크의 디스플레이로 미러링(mirroring)할 수 있다. WFD 소스와 WFD 싱크는 서로 간에 제 1 시퀀스 메시지를 교환하여 디바이스 탐색 및 서비스 탐색 절차를 수행할 수 있다.
WFD 소스와 WFD 싱크 간의 디바이스 탐색 절차 및 서비스 탐색 절차가 완료된 후, 인터넷 프로토콜(internet protocol, 이하, 'IP') 주소가 WFD 소스 및 WFD 싱크 각각을 위해 할당될 수 있다. WFD 소스와 WFD 싱크 사이에 전송 제어 프로토콜(transmission control protocol, 이하 ''TCP') 연결이 확립된 후, WFD 소스 및 WFD 싱크를 위한 실시간 스트리밍 프로토콜(real time streaming protocol, 이하 'RTSP') 스택 및 실시간 프로토콜(real time protocol, 이하 'RTP') 스택이 활성화될 수 있다.
WFD 소스와 WFD 싱크 간에 능력 협상 절차(capability negotiation procedure)는 RTSP를 통해 수행될 수 있다. 능력 협상 절차가 수행되는 동안 WFD 소스와 WFD 싱크는 RTSP 기반의 메시지(즉, M1 내지 M4)를 교환할 수 있다. 이후, WFD 소스와 WFD 싱크는 WFD 세션 제어 메시지들을 교환할 수 있다.
또한, WFD 소스와 WFD 싱크 사이에는 RTP를 통한 데이터 세션이 확립될 수 있다. WFD 네트워크에서 데이터 전달(data transport)을 위해 사용자 데이터그램 프로토콜(User Datagram Protocol, 이하, UDP)이 사용될 수 있다.
도 2는 WFD 네트워크를 보여주는 예시적인 블록도이다. 도 2를 참조하면, WFD 소스(200) 및 WFD 싱크(250)는 WFD 장치로서 특정한 연결 기법(예를 들어, WiFi-P2P 기법)를 기반으로 연결될 수 있다.
예를 들어, 도 2의 WFD 소스(200)는 P2P 링크를 통해 멀티미디어 컨텐츠의 스트리밍을 지원하는 장치일 수 있다. 예를 들어, WFD 싱크(250)는 P2P 링크를 통해 WFD 소스(200)로부터 수신된 멀티미디어 컨텐츠를 기반으로 이미지 및/또는 사운드를 생성하는 절차를 수행(즉, 렌더링 절차를 수행)하는 장치일 수 있다.
예를 들어, 도 2의 WFD 싱크(250)는 프라이머리(primary) 싱크 또는 세컨더리(secondary) 싱크일 수 있다. 일 예로, 세컨더리 싱크는 WFD 소스(200)로부터 오디오 페이로드만 렌더링할 수 있다.
도 3은 WFD 세션을 보여주는 예시적인 개념도이다.
도 3의 상단 첫번째 도면을 참조하면, 도 3의 WFD 소스(300)는 오디오 단독 세션을 기반으로 프라이머리 싱크(305) 또는 세컨더리 싱크(310)와 연결될 수 있다.
도 3의 상단 두번째 도면을 참조하면, WFD 소스(320)는 비디오-단독(video-only) 세션을 기반으로 프라이머리 싱크(325)와 연결될 수 있다.
도 3의 상단 세번째 도면을 참조하면, WFD 소스(340)는 오디오 및 비디오 세션을 기반으로 프라이머리 싱크(345)와 연결될 수 있다.
도 3의 상단 네번째 도면을 참조하면, 커플드 싱크(coupled WFD Sink) 동작에 따른 세션 연결이 도시된다.
예를 들어, 프라이머리 싱크(365)는 비디오를 렌더링하고, 세컨더리 싱크(370)는 오디오를 렌더링할 수 있다. 다른 예로, 프라이머리 싱크(365)가 비디오 및 오디오를 모두 렌더링할 수도 있다. 참고로, 도 3에 도시된 다양한 방식의 WFD 세션은 하기 도 4를 통해 설명될 절차를 수행한 이후 확립될 수 있다.
도 4는 WFD 세션 설정 방법을 나타낸 개념도이다.
도 4를 참조하면, WFD 장치 탐색 절차(WFD Device Discovery, S401), WFD 서비스 탐색 절차(WFD Service Discovery, S402), WFD 연결 셋업 절차(WFD Connection Setup, S403) 및 능력 교환 및 협상 절차(Capability Exchange and Negotiation, S404)가 수행된 이후, WFD 소스 및 WFD 싱크 사이에는 WFD 세션이 확립(establish)될 수 있다.
도 4의 S401 단계에서, WFD 소스는 WFD 장치 탐색 절차를 수행하여 WFD를 위한 피어 장치(즉, WFD 싱크)를 찾을 수 있다.
예를 들어, WFD 장치 탐색 절차를 위해 WFD 소스 및 WFD 싱크에 의해 전송되는 비콘 프레임, 프로브 요청 프레임 및 프로브 응답 프레임은 WFD 정보 요소(Information Element, 이하 'IE')를 포함할 수 있다. 여기서, WFD IE는 장치 타입 또는 장치 상태와 같은 WFD와 연관된 정보를 포함할 수 있다.
구체적으로, WFD 소스는 WFD IE를 포함하는 프로브 요청 프레임을 WFD 싱크로 전송할 수 있다. WFD 싱크는 프로브 요청 프레임에 대한 응답으로 WFD IE를 포함하는 프로브 응답 프레임을 전송할 수 있다.
만일 WFD 장치가 인프라스트럭처 AP와 결합된 상태에서 Wi-Fi P2P 장치로 동작하는 경우, 프로브 요청 프레임에는 WFD IE 및 P2P 정보 요소가 모두 포함될 수 있다.
프로브 요청 프레임에 대한 응답인 프로브 응답 프레임은 프로브 요청 프레임이 수신된 채널과 같은 채널을 통해 전송될 수 있다. 또한, 프로브 응답 프레임은 P2P IE 및 WFD IE를 모두 포함할 수 있다.
도 4를 통해 언급되지 않은 WFD 장치 탐색과 관련된 내용들은 2017년 7월에 발간된 'Wi-Fi Display Technical Specification v2.1' 문서에 따를 수 있으며, 이는 이하의 설명들에도 적용될 수 있음은 이해될 것이다.
도 4의 S402 단계에서, WFD 장치 탐색을 수행한 WFD 소스 및 WFD 싱크 상호 간의 서비스 능력에 대한 탐색이 수행될 수 있다. 단, WFD 서비스 탐색 절차는 선택적인 절차일 수 있다.
예를 들어, WFD 소스가 WFD 능력(capability)에 대한 정보를 포함하는 서비스 탐색 요청 프레임을 전송하면 WFD 싱크는 서비스 탐색 요청 프레임에 대한 응답으로 WFD 능력에 대한 정보를 포함하는 서비스 탐색 응답 프레임이 전송될 수 있다.
도 4의 S403 단계에서, WFD 장치(예로, WFD 소스)는 WFD 연결 셋업을 위한 WFD 장치(예로, WFD 싱크)를 선택할 수 있다. 예를 들어, 정책(policy) 또는 사용자 입력 등에 따라 WFD 연결 셋업을 위한 WFD 장치(예로, WFD 싱크)가 선택될 수 있다. 이어, 선택된 WFD 장치(예로, WFD 싱크)와의 WFD 연결을 위해 특정한 연결 기법(예를 들어, Wi-Fi P2P 또는 Tunneled Direct Link Setup, 이하 'TDLS')이 사용될 수 있다.
예를 들어, WFD 장치는 선호되는 연결(preferred connectivity) 정보 및 WFD 정보 요소(WFD IE)에 의해 운반되는 결합 BSSID 부요소(an Associated basic service set identifier subelement)를 기반으로 연결 기법(connectivity scheme)을 결정할 수 있다.
도 4의 S404 단계에서, WFD 소스 및 WFD 싱크 사이에 능력 교환 절차 및 협상 절차가 수행될 수 있다. S404 단계에 대하여는 후술될 도 6을 참조하여 더 상세하게 설명된다.
도 5는 WFD 소스와 WFD 싱크 간의 네트워크를 나타낸 개념도이다.
도 5의 상단을 참조하면, WFD 소스(500)는 Wi-Fi P2P 링크를 기반으로 WFD 싱크(510)와 연결될 수 있다. 예를 들어, WFD 소스(500) 및 WFD 싱크(510)는 같은 AP와 결합될 수 있다. 다른 예로, WFD 소스(500) 및 WFD 싱크(510)는 각기 다른 AP와 결합될 수 있다. 또 다른 예로, WFD 소스(500) 및 WFD 싱크(510)는 별도의 AP와 결합되지 않을 수도 있다.
도 5의 하단을 참조하면, 소스(550)는 TDLS 링크를 기반으로 WFD 싱크(560)와 연결될 수 있다. 예를 들어, TDLS 링크를 사용하여 WFD 연결이 수행될 때, WFD 소스(550)는 WFD 소스(550)와 결합된 AP와의 연결을 유지해야 한다. 또한, TDLS 링크를 사용하여 WFD 연결이 수행될 때, WFD 싱크(560)는 WFD 싱크(560)와 결합된 AP와의 연결을 유지해야 한다. 이 경우, WFD 소스(550)가 연결을 유지하는 AP와 WFD 싱크(560)가 연결을 유지하는 AP는 같을 수 있다.
도 5의 일 예에 따르면, WFD 소스와 WFD 싱크 사이에 와이파이 다이렉트(즉, P2P) 또는 TDLS 링크가 사용되는 경우가 도시되나, 본 명세서가 이에 한정되는 것이 아니다.
WFD 능력 교환 및 협상 절차는 WFD 장치들 사이에 WFD 연결 셋업 절차 이후에 수행될 수 있다. WFD 능력 교환 및 협상을 통해 WFD 소스 및 WFD 싱크는 서로가 지원하는 코덱, 코덱의 프로파일 정보, 코덱의 레벨 정보 및 해상도 정보 중 적어도 하나 이상의 정보를 상호 간에 교환할 수 있다.
WFD 능력 교환 및 협상은 RTSP(Real Time Streaming Protocol)를 이용한 메시지를 교환함으로써 수행될 수 있다. 또한, WFD 세션 동안, 오디오/비디오 페이로드를 정의하기 위한 파라미터 집합이 결정될 수 있다. 구체적으로, 후술될 도 6에 도시된 바와 같이, WFD 능력 교환 및 협상 절차는 RTSP M1부터 RTSP M4 메시지의 교환에 의해 수행될 수 있다.
도 6은 WFD 능력 교환 협상(WFD capability negotiation)을 위한 절차를 보여주는 개념도이다.
도 6은 앞선 도 4를 통해 언급된 절차가 수행된 이후, L3 연결(L3 connectivity)이 성공적으로 완료됨을 전제로 설명된다. 즉, 도 6의 WFD 소스 및 WFD 싱크를 위해 하나의 IP 주소가 할당될 수 있다.
S601 단계에서, WFD 소스는 RSTP 절차 및 WFD 능력 협상을 시작하기 위한 RTSP M1 요청 메시지를 전송할 수 있다. 예를 들어, RTSP M1 요청 메시지는 RTSP OPTIONS Request를 포함할 수 있다.
RTSP M1 요청 메시지가 수신된 이후, S602 단계에서, WFD 싱크는 자신이 지원하는 RTSP 메소드가 열거된 RTSP M1 응답 메시지를 전송할 수 있다. 예를 들어, RTSP M1 응답 메시지는 RTSP OPTIONS Response를 포함할 수 있다.
S603 단계에서, WFD 싱크는 WFD 소스에서 지원하는 RTSP 메소드 집합을 결정하기 위한 RTSP M2 요청 메시지를 전송할 수 있다. 예를 들어, RTSP M2 요청 메시지는 RTSP OPTIONS Request를 포함할 수 있다.
RTSP M2 요청 메시지가 수신된 이후, S604 단계에서, WFD 소스는 자신이 지원하는 RTSP 메소드가 열거된 RTSP M2 응답 메시지로 응답할 수 있다. 예를 들어, RTSP M2 응답 메시지는 RTSP OPTIONS Response를 포함할 수 있다.
S605 단계에서, WFD 소스는 WFD 싱크의 속성(attributes) 및 WFD 싱크의 능력(capabilities)을 쿼리(query)하기 위하여 RTSP M3 요청 메시지를 전송할 수 있다. 예를 들어, RTSP M3 요청 메시지는 RTSP GET_PARAMETER Request를 포함할 수 있다.
예를 들어, RTSP M3 요청 메시지는 WFD 소스가 WFD 싱크로부터 획득하고자 하는 WFD 싱크의 능력(capabilities)에 대한 리스트를 명시적으로 구체화(explicitly specify)할 수 있다.
RTSP M3 요청 메시지가 수신되면, S606 단계에서, WFD 싱크는 RTSP M3 응답 메시지로 응답할 수 있다. 예를 들어, RTSP M3 응답 메시지는 RTSP GET_PARAMETER Response를 포함할 수 있다.
예를 들어, RTSP M3 응답 메시지가 RTSP OK의 상태 코드(status code)를 포함할 때, RTSP M3 응답 메시지는 RTSP M3 요청 메시지에 따라 요청된 WFD 싱크의 파라미터의 값들을 포함할 수 있다.
WFD 소스는 RTSP M3 응답 메시지를 기반으로 WFD 세션 동안 사용될 최적의 파라미터 집합을 결정할 수 있다.
S607 단계에서, WFD 소스는 결정된 파라미터 집합을 포함하는 RTSP M4 요청 메시지를 WFD 싱크로 전송할 수 있다. 예를 들어, RTSP M4 요청 메시지는 RTSP SET_PARAMETER Request를 포함할 수 있다.
RTSP M4 요청 메시지가 수신되면, S608 단계에서, WFD 싱크는 RTSP M4 응답 메시지로 응답할 수 있다. 예를 들어, RTSP M4 응답 메시지는 RTSP SET_PARAMETER Response를 포함할 수 있다.
도 6에 언급된 S601 단계 내지 S608 단계가 수행되면, WFD 소스 및 WFD 싱크 사이의 능력 교환을 위한 절차가 완료될 수 있다.
도 7은 WFD 세션 확립(WFD session establishment)을 위한 절차를 보여주는 개념도이다. 도 1 내지 도 7을 참조하면, 도 7은 S601 단계 내지 S608 단계가 선행적으로 수행됨을 전제로 설명된다.
S701 단계에서, WFD 소스는 RTSP SET 파라미터 요청 메시지(RTSP M5 Trigger SETUP request)를 WFD 싱크로 전송할 수 있다.
S702 단계에서, WFD 싱크는 RTSP SET 파라미터 요청 메시지에 대한 응답으로 RTSP M5 응답 메시지(RTSP M5 response message)를 WFD 소스로 전송할 수 있다.
S703 단계에서, 트리거 파라미터 설정(SETUP)을 포함하는 RTSP M5 메시지가 성공적으로 교환되면, WFD 싱크는 RTSP SETUP 요청 메시지(RTSP M6 request)를 WFD 소스로 전송할 수 있다.
S704 단계에서, RTSP M6 요청 메시지가 수신되면, WFD 소스는 RTSP SETUP 응답 메시지(RTSP M6 response)를 WFD 싱크로 전송할 수 있다. 예를 들어, RTSP Μ6 응답 메시지에 포함된 상태 코드의 설정을 통해 RTSP 세션의 성공적인 구축이 지시될 수 있다.
S705 단계에서, RTSP M6 메시지의 성공적인 교환 이후, WFD 싱크는 RTP 스트림(RTP stream)을 수신할 준비가 되었음을 알리기 위해 RTSP PLAY 요청 메시지(RTSP M7 request message)를 WFD 소스로 전송할 수 있다.
S706 단계에서, WFD 소스는 RTSP PLAY 응답 메시지(RTSP M7 response message)를 WFD 싱크로 전송할 수 있다.
예를 들어, RTSP PLAY 응답 메시지에 포함된 상태 코드를 기반으로 WFD 세션의 성공적인 확립이 지시될 수 있다.
WFD 세션이 확립된 후, WFD 소스는 WFD 싱크로 WFD 싱크에서 지원하는 적어도 하나의 RTSP 파라미터에 대한 능력을 획득하기 위한 RTSP M3 요청 메시지(RTSP GET_PARAMETER 요청 메시지), AV(Audio/Video) 포맷 갱신을 위한 WFD 소스 및 WFD 싱크 사이의 능력 재협상을 위해 WFD 세션에 대응하는 적어도 하나의 RTSP 파라미터 값을 설정하기 위한 RTSP M4 요청 메시지, WFD 싱크가 RTSP PAUSE 요청 메시지(RTSP M9 요청 메시지)를 전송하도록 트리거하는 RTSP M5 요청 메시지， WFD 소스가 WFD 대기 모드(standby mode)로 진입함을 지시하는 RTSP M12 요청 메시지, UIBC(user input back channel)에서 사용될 입력 타입, 입력 장치 및 다른 파라미터들을 선택하기 위한 RTSP M14 요청 메시지 또는 UIBC(user input back channel)를 활성화(enable) 또는 비활성화(disable)하기 위한 RTSP M15 요청 메시지 등을 WFD 싱크로 전송할 수 있다.
WFD 소스로부터 전술한 RTSP 요청 메시지를 수신한 WFD 싱크는 RTSP 응답 메시지로 응답할 수 있다.
계속해서, WFD 싱크는 오디오/비디오 스트리밍을 시작(또는 재개)하기 위한 RTSP M7 요청 메시지(RTSP PLAY 요청 메시지), WFD 소스로부터 WFD 싱크로 전송되는 오디오/비디오 스트리밍의 일시 중단을 위한 RTSP M9 요청 메시지(RTSP PAUSE 요청 메시지), WFD 소스에게 오디오 렌더링 장치를 변경할 것을 요청하기 위한 RTSP M10 요청 메시지， 활성 커넥터 타입(active connector type)의 변경을 지시하는 RTSP M11 요청 메시지, WFD 싱크가 WFD 대기 모드로 진입하였음을 지시하는 RTSP M12 요청 메시지, WFD 소스에게 IDR(instantaneous decoding refresh)을 리프레시할 것을 요청하는 M13 요청 메시지, UIBC에서 사용될 입력 타입, 입력 장치 및 다른 파라미터들을 선택하기 위한 RTSP M14 요청 메시지 또는 UIBC의 활성화(enable) 또는 비활성화(disable)를 위한 RTSP M15 요청 메시지 등을 WFD 소스로 전송할 수 있다.
WFD 싱크로부터 상기 열거된 RTSP 요청 메시지를 수신한 WFD 소스는 RTSP 응답 메시지로 응답할 수 있다.
WFD 세션이 구축되고, 오디오/비디오 스트리밍이 시작되면, WFD 소스 및 WFD 싱크는 양자가 공통으로 지원하는 코덱을 이용하여 오디오/비디오 스트리밍을 진행할 수 있다. WFD 소스와 WFD 싱크가 공통으로 지원하는 코덱을 이용함에 따라 양자간의 상호 운용성(interoperability)이 보장할 수 있다.
도 8은 본 일 실시 예에 따른 무선랜 시스템에서 음성 명령을 기반으로 화면 미러링을 지원하기 위한 순서도이다. 도 8은 WFD 싱크 장치(820)에서 사용자의 음성 명령이 해석됨을 전제로 설명된다.
도 8을 참조하면, 앞선 도 6 및 도 7의 절차를 통해, 도 8의 WFD 소스 장치(810) 및 WFD 싱크 장치(820) 사이에 오디오/비디오 스트리밍을 위한 WFD 세션이 확립됨이 전제될 수 있다.
S810 단계에서, WFD 싱크 장치(820)은 사용자로부터 음성 명령을 수신할 수 있다. 예를 들어, 음성 명령은 사용자의 음성 데이터일 수 있다.
즉, 음성 데이터는 WFD 소스 장치의 특정한 어플리케이션의 실행을 요청하는 로우 데이터(raw data)일 수 있다. 이 경우, 로우 데이터는 “카카오톡 실행해줘”와 같은 사용자의 음성 명령일 수 있다.
S820 단계에서, WFD 싱크 장치(820)는 사용자의 음성 명령을 해석할 수 있다. 예를 들어, WFD 싱크 장치(820)은 사용자의 음성 명령을 명령어로 해석할 수 있다.
S830 단계에서, WFD 싱크 장치(820)는 WFD 소스 장치(810)의 어플리케이션을 제어하기 위한 RTSP M30 요청 메시지를 WFD 소스 장치(810)로 송신할 수 있다.
예를 들어, RTSP M30 요청 메시지는 S820 단계에서 해석된 명령어를 포함할 수 있다. 예를 들어, RTSP M30 요청 메시지는 식별 필드 및 제어 필드를 포함할 수 있다.
예를 들어, 식별 필드에는 WFD 소스 장치(810)의 특정한 어플리케이션을 식별하기 위한 어플리케이션 ID 정보(예로, “com.kakao.talk”)가 포함될 수 있다. 여기서, 어플리케이션 ID 정보는 어플리케이션 패키지 네임(application package name)으로 언급될 수 있다.
예를 들어, 제어 필드는 3비트 길이의 제어 파라미터(control parameter) 정보를 포함할 수 있다.
일 예로, 제어 파라미터 정보에 '0'에 상응하는 값이 설정될 때, RTSP M30 요청 메시지를 수신한 WFD 소스 장치(810)는 식별 필드에 의해 식별되는 어플리케이션을 실행시킬 수 있다.
다른 일 예로, 제어 파라미터 정보에 '1'에 상응하는 값이 설정될 때, RTSP M30 요청 메시지를 수신한 WFD 소스 장치(810)는 식별 필드에 의해 식별되는 어플리케이션을 종료시킬 수 있다. 참고로, 제어 필드를 위한 '2' 내지 '7'에 상응하는 값은 예약(reserved)될 수 있다.
S840 단계에서, WFD 소스 장치(810)는 RTSP M30 요청 메시지를 기반으로 특정한 어플리케이션을 실행시킬 수 있다.
예를 들어, 어플리케이션 ID 정보 및 제어 파라미터 정보는 WFD 소스 장치(810)에 설치된 어플리케이션의 실행을 담당하는 내부 모듈(일 예로, Framework)로 전달될 수 있다. .
S850 단계에서, WFD 소스 장치(810)는 RTSP M30 요청 메시지에 대한 응답으로 RTSP M30 응답 메시지를 WFD 싱크 장치(820)로 송신할 수 있다.
예를 들어, RTSP M30 응답 메시지에는 RTSP M30 요청 메시지의 성공적인 수신을 알리기 위한 ACK 정보가 포함될 수 있다.
S860 단계에서, 화면 미러링을 수행하기 위하여, WFD 소스 장치(810)는 RTSP M30 요청 메시지에 따른 특정한 어플리케이션에 관한 데이터 스트림을 WFD 싱크 장치(820)로 송신할 수 있다.
예를 들어, 특정한 어플리케이션에 관한 데이터 스트림은 WFD 소스 장치(810) 및 WFD 싱크 장치(820) 사이에 미리 확립된 WFD 세션을 통해 송신될 수 있다.
도 9는 본 다른 실시 예에 따른 무선랜 시스템에서 음성 명령을 기반으로 화면 미러링을 지원하기 위한 순서도이다. 도 9는 WFD 소스 장치(910)에서 사용자의 음성 명령이 해석됨을 전제로 설명된다.
도 9를 참조하면, 앞선 도 6 및 도 7의 절차를 통해, 도 9의 WFD 소스 장치(910) 및 WFD 싱크 장치(920) 사이에 오디오/비디오 스트리밍을 위한 WFD 세션이 확립됨이 전제될 수 있다.
S910 단계에서, WFD 싱크 장치(920)는 사용자로부터 음성 명령을 수신할 수 있다. 예를 들어, 음성 명령은 사용자의 음성 데이터일 수 있다.
즉, 음성 데이터는 WFD 소스 장치의 특정한 어플리케이션의 실행을 요청하는 로우 데이터(raw data)일 수 있다. 이 경우, 로우 데이터는 “카카오톡 실행해줘”와 같은 사용자의 음성 명령일 수 있다.
S920 단계에서, WFD 싱크 장치(920)는 사용자의 음성 명령과 연관된 로우 데이터를 포함하는 RTSP M31 요청 메시지를 WFD 소스 장치(910)로 송신할 수 있다.
S930 단계에서, WFD 소스 장치(910)는 RTSP M31 요청 메시지에 대한 응답으로 RTSP M31 응답 메시지를 WFD 싱크 장치(920)로 송신할 수 있다.
예를 들어, RTSP M31 응답 메시지에는 RTSP M31 요청 메시지의 성공적인 수신을 알리기 위한 ACK 정보가 포함될 수 있다.
S940 단계에서, WFD 소스 장치(910)는 RTSP M31 요청 메시지에 포함된 사용자의 음성 명령을 해석할 수 있다. 예를 들어, WFD 소스 장치(910)는 사용자의 음성 명령을 명령어로 해석할 수 있다.
예를 들어, S940 단계에서 해석된 명령어는 WFD 소스 장치(910)의 특정한 어플리케이션을 식별하기 위한 어플리케이션 ID 정보(예로, “com.kakao.talk”) 및 WFD 소스 장치(910)의 동작을 제어하기 위한 제어 파라미터(control parameter) 정보를 포함할 수 있다.
여기서, 어플리케이션 ID 정보는 어플리케이션 패키지 네임(application package name)으로 언급될 수 있다.
예를 들어, 제어 파라미터 정보는 3비트 길이를 갖도록 구현될 수 있다.
일 예로, 제어 파라미터 정보에 '0'에 상응하는 값이 설정된 경우, WFD 소스 장치(910)는 어플리케이션 ID 정보에 의해 식별되는 어플리케이션을 실행시킬 수 있다.
다른 일 예로, 제어 파라미터 정보에 '1'에 상응하는 값이 설정된 경우, WFD 소스 장치(910)는 어플리케이션 ID 정보에 의해 식별되는 어플리케이션을 종료시킬 수 있다. 참고로, 제어 파라미터 정보를 위한 '2' 내지 '7'에 상응하는 값은 예약(reserved)될 수 있다.
S950 단계에서, WFD 소스 장치(910)는 해석된 명령어를 기반으로 특정한 어플리케이션을 실행시킬 수 있다.
예를 들어, 어플리케이션 ID 정보 및 제어 파라미터 정보는 WFD 소스 장치(910)에 설치된 어플리케이션의 실행을 담당하는 내부 모듈(일 예로, Framework)로 전달될 수 있다.
S960 단계에서, 화면 미러링을 수행하기 위하여, WFD 소스 장치(910)는 해석된 명령어에 따른 특정한 어플리케이션에 관한 데이터 스트림을 WFD 싱크 장치(920)로 송신할 수 있다.
예를 들어, 특정한 어플리케이션에 관한 데이터 스트림은 WFD 소스 장치(910) 및 WFD 싱크 장치(920) 사이에 미리 확립된 WFD 세션을 통해 송신될 수 있다.
도 10은 본 일 실시 예에 따른 무선랜 시스템에서 음성 명령의 해석하는 주체를 결정하기 위한 순서도이다.
도 6 내지 도 10을 참조하면, S1010 단계에서, WFD 소스 장치(1010)는 RTSP GET_PARAMETER Request를 포함하는 RTSP M3 요청 메시지를 WFD 싱크 장치(1020)로 전송할 수 있다.
예를 들어, 도 10의 RTSP M3 요청 메시지는 도 6의 RTSP M3 요청 메시지에 사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하기 위한 파라미터 정보(예로, wfd_voice_command_capability)가 더 포함될 수 있다.
S1020 단계에서, WFD 소스 장치(1010)는 RTSP M3 요청 메시지에 대한 응답으로 RTSP GET_PARAMETER response를 포함하는 RTSP M3 응답 메시지를 수신할 수 있다.
예를 들어, 도 10의 RTSP M3 응답 메시지에는 도 6의 RTSP M3 응답 메시지에 사용자의 음성 데이터의 해석에 관한 능력 정보(예로, wfd_voice_command_capability)가 더 포함될 수 있다.
이 경우, 능력 정보(예로, wfd_voice_command_capability)는 1비트 정보일 수 있다. 예를 들어, WFD 싱크 장치(1020)가 사용자의 음성 데이터의 해석을 지원하지 않는 경우, 능력 정보(예로, wfd_voice_command_capability)는 '0'으로 설정될 수 있다.
예를 들어, WFD 싱크 장치(1020)가 사용자의 음성 데이터의 해석을 지원하는 경우, 능력 정보(예로, wfd_voice_command_capability)는 '1'로 설정될 수 있다.
본 일 실시 예에 따른 WFD 소스 장치(1010)는 능력 정보를 기반으로 사용자의 음성 데이터를 해석하는 주체를 판단할 수 있다.
예를 들어, WFD 싱크 장치(1020)에 의해 음성 데이터의 해석이 지원될 때, WFD 소스 장치(1010)는 WFD 싱크 장치(1020)를 음성 데이터를 해석하는 주체로 판단할 수 있다.
예를 들어, WFD 싱크 장치(1020)에 의해 음성 데이터의 해석이 지원되지 않을 때, WFD 소스 장치(1010)는 자신을 음성 데이터를 해석하는 주체로 판단할 수 있다.
S1030 단계에서, WFD 소스 장치(1010)는 RTSP SET_PARAMETER Request를 포함하는 RTSP M4 요청 메시지를 WFD 싱크 장치(920)로 전송할 수 있다.
예를 들어, 도 10의 RTSP M4 요청 메시지에는 도 6의 RTSP M4 요청 메시지에 음성 데이터를 해석하는 주체와 연관된 역할 정보(예로, wfd_voice_command_role)가 더 포함될 수 있다.
이 경우, 역할 정보(예로, wfd_voice_command_role)는 1비트 정보일 수 있다. 예를 들어, WFD 소스 장치(1010)가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 역할 정보(예로, wfd_voice_command_role)는 '0'으로 설정될 수 있다.
예를 들어, WFD 싱크 장치(920)가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 역할 정보(예로, wfd_voice_command_role)는 '1'로 설정될 수 있다.
S1040 단계에서, WFD 소스 장치(1010)는 RTSP M4 요청 메시지에 대한 응답으로 RTSP SET_PARAMETER Response를 포함하는 RTSP M4 응답 메시지를 수신할 수 있다. 예를 들어, RTSP M4 응답 메시지에는 RTSP M4 요청 메시지에 대한 승인 정보가 포함될 수 있다.
만일 사용자의 음성 데이터를 해석하는 주체가 S1010 단계 내지 S1030 단계를 통해 WFD 싱크 장치로 판단된 경우, 수순은 도 8로 진행될 수 있다.
또한, 만일 사용자의 음성 데이터를 해석하는 주체가 S1010 단계 내지 S1030 단계를 통해 WFD 소스 장치로 판단된 경우, 수순은 도 9로 진행될 수 있다.
도 11은 본 일 실시 예에 따른 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법을 보여주는 순서도이다.
도 1 내지 도 11을 참조하면, 도 11의 제1 무선 장치는 WFD 소스 장치와 상응하고, 도 11의 제2 무선 장치는 WFD 싱크 장치와 상응할 수 있다.
S1110 단계에서, 제1 무선 장치는 사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하는 제1 메시지를 제2 무선 장치로 송신할 수 있다.
예를 들어, 도 11의 제1 메시지는 도 6 및 도 10의 RTSP M3 요청 메시지로 이해될 수 있다.
S1120 단계에서, 제1 무선 장치는 제1 메시지에 대한 응답으로 제2 무선 장치의 능력 정보를 포함하는 제2 메시지를 수신할 수 있다.
예를 들어, 도 11의 제2 메시지는 도 6 및 도 10의 RTSP M3 응답 메시지로 이해될 수 있다. 이 경우, 능력 정보(예로, wfd_voice_command_capability)는 1비트 정보일 수 있다.
예를 들어, 능력 정보(예로, wfd_voice_command_capability)가 '0'으로 설정된 경우, 제1 무선 장치는 제2 무선 장치가 사용자의 음성 데이터의 해석을 지원하지 않음을 알 수 있다.
예를 들어, 능력 정보(예로, wfd_voice_command_capability)가 '1'로 설정된 경우, 제1 무선 장치는 제2 무선 장치가 사용자의 음성 데이터의 해석을 지원함을 알 수 있다.
S1130 단계에서, 제1 무선 장치는 능력 정보를 기반으로 사용자의 음성 데이터를 해석하는 주체를 판단할 수 있다.
예를 들어, 제2 무선 장치에 의해 음성 데이터의 해석이 지원될 때, 제1 무선 장치는 제2 무선 장치를 음성 데이터를 해석하는 주체로 판단할 수 있다.
예를 들어, 제2 무선 장치에 의해 음성 데이터의 해석이 지원되지 않을 때, 제1 무선 장치는 자신을 음성 데이터를 해석하는 주체로 판단할 수 있다.
S1140 단계에서, 제1 무선 장치는 S1130 단계의 판단에 기반한 역할 정보를 포함하는 제3 메시지를 제2 무선 장치로 송신할 수 있다.
이 경우, 역할 정보(예로, wfd_voice_command_role)는 1비트 정보일 수 있다. 예를 들어, 제1 무선 장치가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 역할 정보(예로, wfd_voice_command_role)는 '0'으로 설정될 수 있다.
예를 들어, 제2 무선 장치가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 역할 정보(예로, wfd_voice_command_role)는 '1'로 설정될 수 있다.
S1150 단계에서, 제1 무선 장치는 역할 정보를 기반으로 제2 무선 장치와 화면 미러링(screen mirroring)을 위한 데이터 처리를 수행할 수 있다.
예를 들어, 제2 무선 장치가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 도 8과 같이, 제1 무선 장치는 제2 무선 장치로부터 제4 메시지를 수신할 수 있다.
이 경우, 도 11의 제4 메시지는 도 8의 RTSP M30 요청 메시지와 상응할 수 있다. 일 예로, 제4 메시지는 제1 무선 장치에 의해 실행될 어플리케이션을 식별하기 위한 제1 정보(즉, 도 8의 식별 필드에 포함된 정보) 및 어플리케이션의 동작을 제어하기 위한 위한 제2 정보(즉, 도 8의 제어 필드에 포함된 정보)를 포함할 수 있다.
나아가, 제2 무선 장치와 화면 미러링을 위하여, 제1 무선 장치는 제1 정보 및 제2 정보를 기반으로 어플리케이션에 관한 데이터 스트림을 제2 무선 장치로 송신할 수 있다.
다른 예로, 제1 무선 장치가 사용자의 음성 데이터를 해석하는 주체로 판단된 경우, 도 9와 같이, 제1 무선 장치는 제2 무선 장치로부터 제4 메시지를 수신할 수 있다.
이 경우, 도 11의 제4 메시지는 도 9의 RTSP M31 요청 메시지와 상응할 수 있다. 일 예로, 사용자의 음성 데이터에 관한 로우 데이터(raw data)를 포함할 수 있다. 또한, 제1 무선 장치는 수신된 로우 데이터를 기반으로 제1 무선 장치에 의해 실행될 어플리케이션을 위한 해석 정보를 생성할 수 있다.
이 경우, 해석 정보는 제1 무선 장치의 특정한 어플리케이션을 식별하기 위한 어플리케이션 ID 정보(예로, “com.kakao.talk”) 및 제1 무선 장치의 동작을 제어하기 위한 제어 파라미터(control parameter) 정보를 포함할 수 있다.
나아가, 제2 무선 장치와 화면 미러링을 위하여, 제1 무선 장치는 해석 정보를 기반으로 어플리케이션을 위한 데이터 스트림을 제2 무선 장치로 송신할 수 있다.
본 일 실시 예에 따르면, WFD 싱크 장치에 입력된 음성 명령을 기반으로 WFD 소스 장치를 구동하는 것이 가능하게 되므로, 사용자의 관점에서 편의성이 증대된 무선 통신이 수행될 수 있다.
도 12 및 도 13은 본 또 다른 실시 예에 따라 UIBC(User Input Back Channel)를 기반으로 화면 미러링을 지원하기 위한 순서도이다.
도 12를 참조하면, UIBC Input Message의 타입 중 HiDC Input message format을 기반으로 사용자의 음성명령이 전달되는 경우가 설명된다.
예를 들어, UIBC를 통해 사용자의 음성명령을 WFD 싱크 장치에서 WFD 소스 장치로 전달하기 위해, 도 6의 RTSP M3 Response message 에 포함되는 wfd_uibc_capability 파라미터는 하기 표 1과 같이 정의될 수 있다.
wfd_uibc_capability: input_category_list = HIDC; hidc_cap_list = VoiceCommand / Wi -Fi, VoiceCommand/BT;
도 12의 UIBC 능력 협상(UIBC capability negotiation) 절차에서, 사용자의 음성 로우 데이터(Raw data)를 소스 디바이스로 전달하거나 사용자의 음성 로우 데이터를 명령어로 해석한 값을 소스 디바이스에 전달하는 능력에 관한 정보가 협상(negotiation)될 수 있다.
도 12의 WFD 싱크 디바이스는 사용자로부터 음성 Raw data (예로, “카카오톡 실행해줘”)를 수신한 경우, WFD 싱크 디바이스는 음성 Raw data를 명령어(예로, “”)로 해석할 수 있다.
예를 들어, WFD 싱크 디바이스에서 해석된 명령어(command)는 UIBC input message에 포함되어 WFD 소스 디바이스에 전달될 수 있다. 예를 들어, UIBC Input message (HIDC input format)는 식별 필드 및 제어 필드를 포함할 수 있다.
예를 들어, 식별 필드에는 WFD 소스 장치의 특정한 어플리케이션을 식별하기 위한 어플리케이션 ID 정보(예로, “com.kakao.talk”)가 포함될 수 있다. 여기서, 어플리케이션 ID 정보는 어플리케이션 패키지 네임(application package name)으로 언급될 수 있다.
예를 들어, 제어 필드는 3비트 길이의 제어 파라미터(control parameter) 정보를 포함할 수 있다.
일 예로, 제어 파라미터 정보에 '0'에 상응하는 값이 설정될 때, UIBC Input message를 수신한 WFD 소스 장치는 식별 필드에 의해 식별되는 어플리케이션을 실행시킬 수 있다.
다른 일 예로, 제어 파라미터 정보에 '1'에 상응하는 값이 설정될 때, UIBC Input message를 수신한 WFD 소스 장치는 식별 필드에 의해 식별되는 어플리케이션을 종료시킬 수 있다. 참고로, 제어 필드를 위한 '2' 내지 '7'에 상응하는 값은 예약(reserved)될 수 있다.
도 13을 참조하면, UIBC capability negotiation 및 WFD Session 설정을 완료 한 WFD 싱크 디바이스는 사용자로부터 음성 Raw data(예로, “카카오톡 실행해줘”)를 수신할 수 있다.
이 경우, WFD 싱크 디바이스는 UIBC Input message를 통해 음성 Raw data를 WFD 소스 디바이스에 전달할 수 있다. WFD 소스 디바이스는 수신된 음성 Raw data를 실행할 수 있는 명령어(예로, “”and control 값: 실행, 종료)로 해석할 수 있다. 이어, WFD 소스 디바이스는 해석한 명령을 실행할 수 있다.
도 14는 본 실시 예가 적용될 수 있는 무선 장치를 나타내는 블록도이다.
도 14를 참조하면, 무선 장치는 상술한 실시 예를 구현할 수 있는 STA로서, AP 또는 non-AP STA로 동작할 수 있다. 또한, 무선 장치는 상술한 사용자(user)에 대응되거나, 사용자에 신호를 송신하는 송신 단말에 대응될 수 있다.
도 14의 무선장치는, 도시된 바와 같이 프로세서(1410), 메모리(1420) 및 트랜시버(1430)를 포함한다. 도시된 프로세서(1410), 메모리(1420) 및 트랜시버(1430)는 각각 별도의 칩으로 구현되거나, 적어도 둘 이상의 블록/기능이 하나의 칩을 통해 구현될 수 있다.
트랜시버(transceiver, 1430)는 송신기(transmitter) 및 수신기(receiver)를 포함하는 장치이며, 특정한 동작이 수행되는 경우 송신기 및 수신기 중 어느 하나의 동작만이 수행되거나, 송신기 및 수신기 동작이 모두 수행될 수 있다.
트랜시버(1430)는 무선 신호를 전송 및/또는 수신하는 하나 이상의 안테나를 포함할 수 있다. 또한, 트랜시버(1430)는 수신 신호 및/또는 송신 신호의 증폭을 위한 증폭기와 특정한 주파수 대역 상으로의 송신을 위한 밴드패스필터를 포함할 수 있다.
프로세서(1410)는 본 명세서에서 제안된 기능, 과정 및/또는 방법을 구현할 수 있다. 예를 들어, 프로세서(1410)는 전술한 본 실시 예에 따른 동작을 수행할 수 있다. 즉, 프로세서(1410)는 도 1 내지 도 12의 실시 예에서 개시된 동작을 수행할 수 있다.
프로세서(1410)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로, 데이터 처리 장치 및/또는 베이스밴드 신호 및 무선 신호를 상호 변환하는 변환기를 포함할 수 있다.
메모리(1420)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
도 15는 프로세서에 포함되는 장치의 일례를 나타내는 블록도이다.
설명의 편의를 위해, 도 15의 일례는 송신 신호를 위한 블록을 기준으로 설명되어 있으나, 해당 블록을 이용하여 수신 신호를 처리할 수 있다는 점은 자명하다.
도시된 데이터 처리부(1510)는 송신 신호에 대응되는 송신 데이터(제어 데이터 및/또는 사용자 데이터)를 생성한다. 데이터 처리부(1510)의 출력은 인코더(1520)로 입력될 수 있다. 인코더(1520)는 BCC(binary convolutional code)나 LDPC(low-density parity-check) 기법 등을 통해 코딩을 수행할 수 있다. 인코더(1520)는 적어도 1개 포함될 수 있고, 인코더(1520)의 개수는 다양한 정보(예를 들어, 데이터 스트림의 개수)에 따라 정해질 수 있다.
인코더(1520)의 출력은 인터리버(1530)로 입력될 수 있다. 인터리버(1530)는 페이딩 등에 의한 연집 에러(burst error)를 방지하기 위해 연속된 비트 신호를 무선 자원(예를 들어, 시간 및/또는 주파수) 상에서 분산시키는 동작을 수행한다. 인터리버(1530)는 적어도 1개 포함될 수 있고, 인터리버(1530)의 개수는 다양한 정보(예를 들어, 공간 스트림의 개수)에 따라 정해질 수 있다.
인터리버(1530)의 출력은 성상 맵퍼(constellation mapper, 1540)로 입력될 수 있다. 성상 맵퍼(1540)는 BPSK(biphase shift keying), QPSK(Quadrature Phase Shift Keying), n-QAM(quadrature amplitude modulation) 등의 성상 맵핑을 수행한다.
성상 맵퍼(1540)의 출력은 공간 스트림 인코더(1550)로 입력될 수 있다. 공간 스트림 인코더(1550)는 송신 신호를 적어도 하나의 공간 스트림을 통해 송신하기 위해 데이터 처리를 수행한다. 예를 들어, 공간 스트림 인코더(1550)는 송신 신호에 대한 STBC(space-time block coding), CSD(Cyclic shift diversity) 삽입, 공간 매핑(spatial mapping) 중 적어도 하나를 수행할 수 있다.
공간 스트림 인코더(1550)의 출력은 IDFT(1560) 블록에 입력될 수 있다. IDFT(1560) 블록은 IDFT(inverse discrete Fourier transform) 또는 IFFT(inverse Fast Fourier transform)을 수행한다.
IDFT(1560) 블록의 출력은 GI(Guard Interval) 삽입기(1570)에 입력되고, GI 삽입기(1570)의 출력은 도 14의 트랜시버(1430)에 입력된다.
본 명세서의 상세한 설명에서는 구체적인 실시 예에 관하여 설명하였으나, 본 명세서의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능하다. 그러므로, 본 명세서의 범위는 상술한 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구범위뿐만 아니라 이 발명의 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (10)

  1. 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법에 있어서,
    제1 무선 장치가, 사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하는 제1 메시지를 제2 무선 장치로 송신하는 단계;
    상기 제1 무선 장치가, 상기 제1 메시지에 대한 응답으로 상기 능력 정보를 포함하는 제2 메시지를 수신하는 단계;
    상기 제1 무선 장치가, 상기 능력 정보를 기반으로 상기 음성 데이터를 해석하는 주체를 판단하는 단계;
    상기 제1 무선 장치가, 상기 판단에 기반한 역할 정보를 포함하는 제3 메시지를 상기 제2 무선 장치로 송신하는 단계; 및
    상기 제1 무선 장치가, 상기 역할 정보를 기반으로 상기 제2 무선 장치와 화면 미러링(screen mirroring)을 위한 데이터 처리를 수행하는 단계를 포함하는 방법.
  2. 제1 항에 있어서,
    상기 제2 무선 장치에 의해 상기 음성 데이터의 해석이 지원될 때, 상기 제2 무선 장치는 상기 음성 데이터를 해석하는 상기 주체로 판단되는 방법.
  3. 제2 항에 있어서,
    상기 제2 무선 장치와 상기 화면 미러링을 위한 상기 데이터 처리를 수행하는 단계는,
    상기 제1 무선 장치가, 상기 제2 무선 장치로부터 제4 메시지를 수신하되,
    상기 제4 메시지는 상기 제1 무선 장치에 의해 실행될 어플리케이션을 식별하기 위한 제1 정보 및 상기 어플리케이션의 동작을 제어하기 위한 위한 제2 정보를 포함하는, 단계; 및
    상기 제1 무선 장치가, 제1 정보 및 제2 정보를 기반으로 상기 어플리케이션에 관한 데이터 스트림을 상기 제2 무선 장치로 송신하는 단계를 포함하는 방법.
  4. 제1 항에 있어서,
    상기 제2 무선 장치에 의해 상기 음성 데이터의 해석이 지원되지 않을 때, 상기 제1 무선 장치는 상기 음성 데이터를 해석하는 상기 주체로 판단되는 방법.
  5. 제4 항에 있어서,
    상기 제2 무선 장치와 상기 화면 미러링을 위한 상기 데이터 처리를 수행하는 단계는,
    상기 제1 무선 장치가, 상기 제2 무선 장치로부터 제4 메시지를 수신하되,
    상기 제4 메시지는 상기 음성 데이터에 관한 로우 데이터(raw data)를 포함하는, 단계;
    상기 제1 무선 장치가, 상기 로우 데이터를 기반으로 상기 제1 무선 장치에 의해 실행될 어플리케이션을 위한 해석 정보를 생성하는 단계; 및
    상기 제1 무선 장치가, 상기 해석 정보를 기반으로 상기 어플리케이션을 위한 데이터 스트림을 상기 제2 무선 장치로 송신하는 단계를 포함하는 방법.
  6. 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법을 수행하는 제1 무선 장치에 있어서, 상기 제1 무선 장치는,
    무선신호를 송수신하는 송수신기; 및
    상기 송수신기에 연결되는 프로세서를 포함하되, 상기 프로세서는,
    사용자의 음성 데이터의 해석에 관한 능력 정보를 요청하는 제1 메시지를 제2 무선 장치로 송신하도록 구현되고,
    상기 제1 메시지에 대한 응답으로 상기 능력 정보를 포함하는 제2 메시지를 수신하도록 구현되고,
    상기 능력 정보를 기반으로 상기 음성 데이터를 해석하는 주체를 판단하도록 구현되고,
    상기 판단에 기반한 역할 정보를 포함하는 제3 메시지를 상기 제2 무선 장치로 송신하도록 구현되고, 그리고
    상기 역할 정보를 기반으로 상기 제2 무선 장치와 화면 미러링(screen mirroring)을 위한 데이터 처리를 수행하도록 구현되는 무선 장치.
  7. 제6 항에 있어서,
    상기 제2 무선 장치에 의해 상기 음성 데이터의 해석이 지원될 때, 상기 제2 무선 장치는 상기 음성 데이터를 해석하는 상기 주체로 판단되는 무선 장치.
  8. 제7 항에 있어서,
    상기 프로세서는,
    상기 제2 무선 장치로부터 제4 메시지를 수신하도록 구현되되,
    상기 제4 메시지는 상기 제1 무선 장치에 의해 실행될 어플리케이션을 식별하기 위한 제1 정보 및 상기 어플리케이션의 동작을 제어하기 위한 위한 제2 정보를 포함하고, 그리고
    제1 정보 및 제2 정보를 기반으로 상기 어플리케이션에 관한 데이터 스트림을 상기 제2 무선 장치로 송신하도록 더 구현되는 무선 장치.
  9. 제6 항에 있어서,
    상기 제2 무선 장치에 의해 상기 음성 데이터의 해석이 지원되지 않을 때, 상기 제1 무선 장치는 상기 음성 데이터를 해석하는 상기 주체로 판단되는 무선 장치.
  10. 제9 항에 있어서,
    상기 프로세서는,
    상기 제2 무선 장치로부터 제4 메시지를 수신하도록 구현되되,
    상기 제4 메시지는 상기 음성 데이터에 관한 로우 데이터(raw data)를 포함하고,
    상기 로우 데이터를 기반으로 상기 제1 무선 장치에 의해 실행될 어플리케이션을 위한 해석 정보를 생성하도록 구현되고, 그리고
    상기 해석 정보를 기반으로 상기 어플리케이션을 위한 데이터 스트림을 상기 제2 무선 장치로 송신하도록 더 구현되는 무선 장치.
PCT/KR2018/016349 2017-12-21 2018-12-20 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치 WO2019125012A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762609236P 2017-12-21 2017-12-21
US62/609,236 2017-12-21

Publications (1)

Publication Number Publication Date
WO2019125012A1 true WO2019125012A1 (ko) 2019-06-27

Family

ID=66993558

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/016349 WO2019125012A1 (ko) 2017-12-21 2018-12-20 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치

Country Status (1)

Country Link
WO (1) WO2019125012A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120082846A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 와이파이 다이렉트 통신 방식에서의 싱크 디바이스에서 소스 디바이스로 사용자의 입력을 송신하기 위한 방법 및 장치
KR20130100448A (ko) * 2012-03-02 2013-09-11 엘지전자 주식회사 이동 단말기 및 그 제어방법
WO2016186352A1 (ko) * 2015-05-21 2016-11-24 엘지전자 주식회사 Uibc를 통한 음성 명령어 처리 방법 및 장치
KR20170007980A (ko) * 2015-07-13 2017-01-23 엘지전자 주식회사 이동 단말기 및 그 제어방법
KR20170126645A (ko) * 2016-05-10 2017-11-20 엘지전자 주식회사 디지털 디바이스 및 그 제어 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120082846A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 와이파이 다이렉트 통신 방식에서의 싱크 디바이스에서 소스 디바이스로 사용자의 입력을 송신하기 위한 방법 및 장치
KR20130100448A (ko) * 2012-03-02 2013-09-11 엘지전자 주식회사 이동 단말기 및 그 제어방법
WO2016186352A1 (ko) * 2015-05-21 2016-11-24 엘지전자 주식회사 Uibc를 통한 음성 명령어 처리 방법 및 장치
KR20170007980A (ko) * 2015-07-13 2017-01-23 엘지전자 주식회사 이동 단말기 및 그 제어방법
KR20170126645A (ko) * 2016-05-10 2017-11-20 엘지전자 주식회사 디지털 디바이스 및 그 제어 방법

Similar Documents

Publication Publication Date Title
WO2012060611A2 (ko) 장치 탐색 방법 및 그를 이용한 통신 장치
WO2017099542A1 (ko) 다중 베이직 서비스 식별자 세트를 이용하는 무선 통신 방법 및 무선 통신 단말
WO2012078000A2 (ko) 무선통신 시스템에서 단말 및 기지국 간 접속 방법 및 그 장치
WO2019164268A1 (ko) 무선랜 시스템에서 무선 연결을 위한 방법 및 이를 이용한 무선 장치
WO2016186403A1 (ko) 무작위 접속을 기초로 복수의 무선 통신 단말로부터 데이터를 수신하는 무선 통신 방법 및 무선 통신 단말
WO2017179901A1 (ko) 다중 사용자 캐스캐이딩 전송을 지원하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
WO2016148406A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼을 이용하여 서비스를 지원하는 방법 및 장치
WO2019177231A1 (ko) 무선랜 시스템에서 타겟 액세스 포인트에 대한 정보를 전달하기 위한 방법 및 이를 이용한 액세스 포인트
WO2016167618A9 (ko) 무선 통신 시스템에서 서비스 디스커버리를 수행하는 방법 및 장치
WO2016111562A1 (ko) Wfd에서 배터리 상태를 리포트하는 방법 및 장치
WO2017196103A1 (ko) Ack를 전송하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
WO2017018823A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼 세션 형성 방법 및 장치
WO2014030894A1 (ko) 무선랜 시스템에서 고속 링크 셋업 방법 및 이를 위한 장치
WO2017043718A1 (ko) Wfd 싱크에 의해 영상의 오리엔테이션을 변화시키는 방법 및 장치
WO2013122395A1 (ko) 무선랜 시스템에서 고속 링크 셋업 방법 및 장치
WO2018074871A1 (ko) 네트워크 얼로케이션 벡터를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
WO2016209019A1 (ko) 무선 통신 시스템에서 mdns를 이용하여 디스커버리를 수행하는 방법 및 장치
WO2016190618A1 (ko) 무선 통신 시스템에서 세션 핸드오버를 수행하는 방법 및 장치
WO2016148550A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼 세션 형성을 수행하는 방법 및 장치
WO2017155271A1 (ko) 무선 통신 시스템에서 트랜스포트를 통해 스트리밍을 제공받는 방법 및 장치
WO2019225829A1 (ko) Ma-usb에 기반한 p2p 통신을 위한 방법 및 이를 이용한 무선 장치
WO2023048472A1 (en) Restricted twt with enhanced multi-link single radio (emlsr) operation
WO2019125012A1 (ko) 무선랜 시스템에서 음성 데이터를 기반으로 무선 통신을 수행하기 위한 방법 및 이를 이용한 무선 장치
WO2017176034A1 (ko) 프래그멘테이션을 이용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
WO2017209463A1 (ko) 무선랜에서 동적 연결 변경 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18891729

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18891729

Country of ref document: EP

Kind code of ref document: A1