WO2020022728A1 - Method for supporting media agnostic universal serial bus (ma-usb) connection, and wireless device using same - Google Patents

Abstract

An operating method in a wireless LAN system, according to various embodiments, comprises the steps of: allowing a first wireless device to transmit, to a second wireless device, a multicast domain name system (mDNS) query message for requesting whether the second wireless device supports a wireless LAN display service and a media agnostic universal serial bus (MA-USB) service; allowing the first wireless device to receive, from the second wireless device, an mDNS response message including information on a first operation mode, of the second wireless device, relating to the wireless LAN display service and information on a second operation mode, of the second wireless device, relating to the MA-USB service; and allowing the first wireless device to identify, on the basis of the mDNS response message, the information on the first operation mode, of the second wireless device, relating to the wireless LAN display service and the second operation mode, of the second wireless device, relating to the MA-USB service, wherein the mDNS query message and the mDNS response message can be transmitted through an access point (AP).

Description

[Correction 31.07.2019] by Rule 26 Method for supporting MA-USB connection and wireless device using same

The present disclosure relates to wireless communication, and more particularly, to a method for supporting a MA-USB connection and a wireless device using the same.

Wireless display transmission technology is a technology that allows the image of the mobile device to be viewed on a large screen TV (television) or monitor. Wireless display transmission technology can be largely divided into a content transmission method and a mirroring method (ie, screen casting).

The content transmission method converts a screen of a mobile device into a signal and then transmits the converted signal to a remote device. In the mirroring method, a content file is streamed to a remote device to simultaneously display an image of the mobile device on the remote device. The mirroring method has the advantage of being able to wirelessly transmit pixel information of the original screen without being dependent on a specific service.

Miracast can be understood as a wireless video transmission standard and wireless display transmission technology created by the WiFi Alliance. Miracast may also be understood as one type following a mirroring scheme.

An object of the present specification is to provide a method for supporting a MA-USB connection via a wireless LAN and a wireless device using the same.

According to various embodiments of the present disclosure, a method of operating in a wireless LAN system includes an mDNS (mDNS) for requesting whether a first wireless device supports a WLAN display service and a MA-USB (Media Agnostic Universal Serial Bus) service of a second wireless device. multicast Domain Name System) query message to the second wireless device; The first wireless device, in response to the mDNS query message, information regarding the first operation mode of the second wireless device related to the WLAN display service and the second wireless device related to the MA-USB service; 2 receiving an mDNS response message from the second wireless device, the mDNS response message comprising information regarding an operation mode; And information about the first operation mode of the second wireless device related to the WLAN display service and the second wireless device related to the MA-USB service, based on the mDNS response message. The method may include identifying a second operation mode, wherein the mDNS query message and the mDNS response message may be transmitted through an access point (AP).

According to one embodiment of the present specification, a method for establishing a MA-USB connection and a wireless device using the same may be provided based on a WFD connection procedure.

1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.

2 is an exemplary block diagram illustrating a WFD network.

3 is an exemplary conceptual diagram illustrating a WFD session.

4 is a conceptual diagram illustrating a method for establishing a WFD session.

5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.

6 is a conceptual diagram showing a procedure for WFD capability exchange negotiation.

7 is a conceptual diagram illustrating a procedure for establishing a WFD session.

8 shows an application example based on the connection according to the MA-USB according to the present embodiment.

9 to 10 illustrate a WFD connection procedure according to the present embodiment.

11 illustrates a procedure of negotiating MA-USB capability information according to the present embodiment.

12 illustrates a procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

FIG. 13 illustrates another procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

14 illustrates another procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

FIG. 15 illustrates another procedure of establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

16 illustrates another procedure of establishing a MA-USB connection based on a WFD connection procedure according to the present embodiment.

FIG. 17 illustrates a procedure of searching for support of a MA-USB service using mDNS Service Discovery.

FIG. 18 illustrates a procedure for searching whether a MA-USB service is supported through a probe request message and a probe response message exchange.

19 is a diagram illustrating an operation of a wireless device to which an example of the present specification is applied.

20 is a block diagram illustrating a wireless device to which the present embodiment can be applied.

21 is a block diagram illustrating an example of an apparatus included in a processor.

The above-described features and the following detailed description are all exemplary for ease of description and understanding of the present specification. That is, the present specification is not limited to this embodiment and may be embodied in other forms. The following embodiments are merely examples to fully disclose the present specification, and are descriptions to convey the present specification to those skilled in the art. Thus, where there are several methods for implementing the components of the present specification, it is necessary to clarify that any of these methods may be implemented in any of the methods or the same.

In the present specification, when there is a statement that a configuration includes specific elements, or when a process includes specific steps, it means that other elements or other steps may be further included. That is, the terms used in the present specification are only for describing specific embodiments and are not intended to limit the concept of the present specification. Furthermore, the described examples to aid the understanding of the invention also include their complementary embodiments.

The terms used herein have the meanings that are commonly understood by those of ordinary skill in the art to which this specification belongs. Terms commonly used should be interpreted in a consistent sense in the context of the present specification. In addition, terms used in the present specification should not be interpreted in an idealistic or formal sense unless the meaning is clearly defined. Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings.

1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.

Referring to FIG. 1, an IEEE 802.11 structure may be composed of a plurality of components, and a WLAN system supporting transparent STA mobility to a higher layer by their interaction may be provided in a wireless local network. area network, hereinafter referred to as "WLAN").

The Basic Service Set (BSS) may be a basic building block of an IEEE 802.11 LAN. Referring to FIG. 1, two BSSs (BSS1 and BSS2) exist and each BSS may include two STAs. For example, STA1 and STA2 may be included in BSS1, and STA3 and STA4 may be included in BSS2.

Here, the STA means a device that operates according to the Medium Access Control (MAC) / PHY (Physical) specification of IEEE 802.11. The station (STA) may include an access point (AP) STA (simply an AP) and a non-AP STA. The AP corresponds to a device that provides a network (eg, WLAN) connection to a non-AP STA through an air interface. The station may be called various names such as a (wireless LAN) device.

The AP may be configured in a fixed or mobile form and may include a portable wireless device (eg, laptop computer, smart phone, etc.) that provides a hot spot. AP is a base station (BS), Node-B, Evolved Node-B (eNB), Base Transceiver System (BTS), femto base station in other wireless communication fields (Femto BS) or the like.

Non-AP STAs generally correspond to devices that a user directly handles, such as laptop computers, PDAs, wireless modems, and smart phones. 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. (Mobile Subscriber Station, MSS) and the like.

Referring to FIG. 1, an ellipse representing a BSS may be understood to represent a coverage area where STAs included in each BSS maintain communication. This area may be referred to as a basic service area (BSA). The most basic type of BSS in an IEEE 802.11 LAN is an independent BSS (IBS).

For example, the IBSS may have a minimal form consisting of only two STAs. In addition, BSS (BSS1 or BSS2) of FIG. 1 is the simplest form and can be understood as a representative example of IBSS. This configuration is possible when STAs can communicate directly. In addition, this type of LAN is not configured in advance but may be configured when a LAN is required. This type of LAN may be referred to as an ad-hoc network.

In an existing WLAN system, operations between devices (ie, AP and STA) in an infrastructure BSS (basic service set) in which an access point (AP) functions as a hub are mainly defined.

The AP may be responsible for a physical layer support function for a wireless / wired connection, a routing function for devices on a network, a function of adding / removing devices to a network, and a service providing function. That is, in the existing WLAN system, devices in a network are connected through APs, but not directly connected to each other.

As a technology to support direct connection between devices, the Wi-Fi Direct (WFD) standard is defined. Wi-Fi Direct (WFD) is a direct communication technology that allows devices (or STAs) to easily connect with each other without an access point basically required in a conventional WLAN system. When Wi-Fi Direct (WFD) is used, a connection is established between devices without complicated setup process to provide various services to the user.

Wi-Fi Direct (WFD) is also called Wi-Fi P2P. Wi-Fi P2P adds a portion to support direct communication between devices while retaining most of the functionality of the existing Wi-Fi standard. Accordingly, there is an advantage in that the device equipped with the Wi-Fi chip (chip) can fully utilize hardware and physical characteristics, and provide P2P communication between devices mainly by upgrading software functions.

There is a device that plays the role of an AP in an existing infrastructure network within a P2P group, which is referred to as a P2P group owner (hereinafter, 'P2P GO') in the P2P specification. Various P2P clients may exist around P2P GO. Only one P2P GO can exist in one P2P group, and all other devices become client devices.

The Wi-Fi Alliance (hereinafter referred to as "WFA") provides various services using the Wi-Fi Direct link (e.g., Send, Play, Display, Print, etc.). Supported Wi-Fi Direct Service (WFDS) is being studied. According to the WFDS, an application may be controlled or managed by an application service platform (hereinafter referred to as "ASP").

The WFDS devices supported by the WFDS may include devices supporting a WLAN system such as a display device, a printer, a digital camera, a projector, and a smartphone. In addition, the WFDS device may include a STA and an AP. WFDS devices in the WFDS network may be directly connected to each other.

The WFD standard is defined to transfer audio / video (AV) data between devices while satisfying high quality and low latency. WFD networks (WFD sessions) with the WFD standard allow Wi-Fi devices to connect to each other in a peer-to-peer manner without going through a home network, office network, or hot-spot network. Can be.

Hereinafter, a device for transmitting and receiving data according to the WFD standard may be expressed by the term WFD device. WFD devices in the WFD network may search for information about the WFD devices (eg, capability information), establish a WFD session, and render content through the WFD session.

A WFD session may be a network between a source device that provides content and a sink device that receives and renders the content. In this specification, the source device may be referred to as a WFD source. In the present specification, a sink device may be referred to as a WFD sink.

The WFD source may mirror 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 perform a device discovery and service discovery procedure by exchanging a first sequence message between each other.

After the device discovery procedure and service discovery procedure between the WFD source and the WFD sink are completed, an internet protocol (hereinafter, referred to as 'IP') address may be allocated for each of the WFD source and the WFD sink. After a transmission control protocol (TCP) connection is established between the WFD source and the WFD sink, a real time streaming protocol (RTSP) stack and real time for the WFD source and the WFD sink. A real time protocol (RTP) stack may be activated.

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 (ie, M1 through M4) during the capability negotiation procedure. The WFD source and the WFD sink may then exchange WFD session control messages.

In addition, a data session via RTP may be established between the WFD source and the WFD sink. User Datagram Protocol (UDP) may be used for data transport in a WFD network.

2 is an exemplary block diagram illustrating a WFD network. Referring to FIG. 2, the WFD source 200 and the WFD sink 250 may be connected as a WFD device based on a specific connection scheme (eg, WiFi-P2P scheme).

For example, the WFD source 200 of FIG. 2 may be a device that supports streaming of multimedia content through a P2P link. For example, the WFD sink 250 may be a device that performs a procedure of generating an image and / or sound based on multimedia content received from the WFD source 200 through a P2P link (ie, performing a rendering procedure). have.

For example, the WFD sink 250 of FIG. 2 may be a primary sink or a secondary sink. For example, the secondary sync may render only the audio payload from the WFD source 200.

3 is an exemplary conceptual diagram illustrating a WFD session.

Referring to the upper first drawing of FIG. 3, the WFD source 300 of FIG. 3 may be connected to the primary sink 305 or the secondary sink 310 based on an audio-only session.

Referring to the upper second view of FIG. 3, the WFD source 320 may be connected with the primary sink 325 based on a video-only session.

Referring to the upper third drawing of FIG. 3, the WFD source 340 may be connected to the primary sink 345 based on an audio and video session.

Referring to the top fourth view of FIG. 3, a session connection according to a coupled WFD Sink operation is shown.

For example, the primary sink 365 can render the video and the secondary sink 370 can render the audio. As another example, primary sync 365 may render both video and audio. For reference, the WFD session in various manners shown in FIG. 3 may be established after performing the procedure to be described with reference to FIG. 4 below.

4 is a conceptual diagram illustrating a method for establishing a WFD session.

4, the WFD device discovery procedure (WFD Device Discovery, S401), the WFD service discovery procedure (WFD Service Discovery, S402), the WFD connection setup procedure (WFD Connection Setup, S403), and the capability exchange and negotiation procedure (Capability Exchange). and Negotiation (S404)), a WFD session may be established between the WFD source and the WFD sink.

In step S401 of FIG. 4, the WFD source may perform a WFD device discovery procedure to find a peer device (ie, WFD sink) for the WFD.

For example, the beacon frame, the probe request frame, and the probe response frame transmitted by the WFD source and the WFD sink for the WFD device discovery procedure may include a WFD information element (IE). Here, the WFD IE may include information associated with the WFD, such as a device type or a device state.

In detail, the WFD source may transmit a probe request frame including the WFD IE to the WFD sink. The WFD sink may transmit a probe response frame including the WFD IE in response to the probe request frame.

If the WFD device operates as a Wi-Fi P2P device in combination with the infrastructure AP, the probe request frame may include both WFD IE and P2P information elements.

The probe response frame, which is a response to the probe request frame, may be transmitted through the same channel in which the probe request frame is received. In addition, the probe response frame may include both a P2P IE and a WFD IE.

Contents related to WFD device discovery not mentioned through FIG. 4 may be according to the document 'Wi-Fi Display Technical Specification v2.1' published in July 2017, which may be applied to the following descriptions. will be.

In operation S402 of FIG. 4, the discovery of the service capability between the WFD source and the WFD sink that performed the discovery of the WFD device may be performed. However, the WFD service discovery procedure may be an optional procedure.

For example, if a WFD source sends a service discovery request frame that contains information about WFD capabilities, the WFD sink sends a service discovery response frame that contains information about WFD capabilities in response to the service discovery request frame. Can be.

In step S403 of FIG. 4, the WFD device (eg, WFD source) may select a WFD device (eg, WFD sink) for WFD connection setup. For example, a WFD device (eg, a WFD sink) for setting up a WFD connection may be selected according to a policy or user input. Subsequently, a specific connection scheme (eg, Wi-Fi P2P or Tunneled Direct Link Setup, hereinafter “TDLS”) may be used for WFD connection with the selected WFD device (eg, WFD sink).

For example, the WFD device may employ a connectivity scheme based on preferred connectivity information and an associated basic service set identifier subelement carried by the WFD Information Element (WFD IE). You can decide.

In step S404 of FIG. 4, a capability exchange procedure and a negotiation procedure may be performed between the WFD source and the WFD sink. Operation S404 will be described in more detail with reference to FIG. 6 to be described later.

5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.

Referring to the upper portion of FIG. 5, the WFD source 500 may be connected to the WFD sink 510 based on a Wi-Fi P2P link. For example, the WFD source 500 and the WFD sink 510 may be combined with the same AP. As another example, the WFD source 500 and the WFD sink 510 may be combined with different APs. As another example, the WFD source 500 and the WFD sink 510 may not be combined with a separate AP.

Referring to the bottom of FIG. 5, the source 550 may be connected to the WFD sink 560 based on the TDLS link. For example, when a WFD connection is made using a TDLS link, the WFD source 550 must maintain a connection with the AP coupled with the WFD source 550. In addition, when a WFD connection is performed using the TDLS link, the WFD sink 560 must maintain a connection with the AP coupled with the WFD sink 560. In this case, an AP to which the WFD source 550 maintains a connection and an AP to which the WFD sink 560 maintains a connection may be the same.

According to the example of FIG. 5, a case in which Wi-Fi Direct (ie, P2P) or TDLS link is used between the WFD source and the WFD sink is illustrated, but the present disclosure is not limited thereto.

The WFD capability exchange and negotiation procedure may be performed after the WFD connection setup procedure between WFD devices. Through the WFD capability exchange and negotiation, the WFD source and the WFD sink may exchange at least one or more of the codec, the profile information, the codec level information, and the resolution information supported by each other.

WFD capability exchange and negotiation may be performed by exchanging messages using the Real Time Streaming Protocol (RTSP). In addition, during the WFD session, a set of parameters for defining the audio / video payload may be determined. Specifically, as shown in FIG. 6 to be described later, the WFD capability exchange and negotiation procedure may be performed by exchange of RTSP M1 to RTSP M4 messages.

6 is a conceptual diagram illustrating a procedure for WFD capability negotiation.

FIG. 6 is described on the premise that L3 connectivity is successfully completed after the procedure mentioned in FIG. 4 is performed. That is, one IP address may be allocated for the WFD source and the WFD sink of FIG. 6.

In step S601, the WFD source may send an RTSP M1 request message to start the RSTP procedure and WFD capability negotiation. For example, the RTSP M1 request message may include an RTSP OPTIONS Request.

After receiving the RTSP M1 request message, in step S602, the WFD sink may transmit an RTSP M1 response message in which the RTSP methods supported by the WFD sink are enumerated. For example, the RTSP M1 response message may include an RTSP OPTIONS Response.

In step S603, the WFD sink may transmit an RTSP M2 request message for determining a set of RTSP methods supported by the WFD source. For example, the RTSP M2 request message may include an RTSP OPTIONS Request.

After receiving the RTSP M2 request message, in step S604, the WFD source may respond with an RTSP M2 response message enumerating the RTSP methods supported by the WFD source. For example, the RTSP M2 response message may include an RTSP OPTIONS Response.

In step S605, the WFD source may transmit an RTSP M3 request message to query the attributes of the WFD sink and the capabilities of the WFD sink. For example, the RTSP M3 request message may include an RTSP GET_PARAMETER Request.

For example, the RTSP M3 request message may explicitly specify a list of capabilities of the WFD sink that the WFD source wants to acquire from the WFD sink.

If the RTSP M3 request message is received, in step S606, the WFD sink may respond with an RTSP M3 response message. For example, the RTSP M3 response message may include an RTSP GET_PARAMETER Response.

For example, when the RTSP M3 response message includes a status code of RTSP OK, the RTSP M3 response message may include values of parameters of the WFD sink requested according to the RTSP M3 request message.

The WFD source may determine the optimal set of parameters to be used during the WFD session based on the RTSP M3 response message.

In step S607, the WFD source may transmit an RTSP M4 request message including the determined parameter set to the WFD sink. For example, the RTSP M4 request message may include an RTSP SET_PARAMETER Request.

If the RTSP M4 request message is received, in step S608, the WFD sink may respond with an RTSP M4 response message. For example, the RTSP M4 response message may include an RTSP SET_PARAMETER Response.

When the steps S601 to S608 mentioned in FIG. 6 are performed, the procedure for the capability exchange between the WFD source and the WFD sink may be completed.

7 is a conceptual diagram illustrating a procedure for WFD session establishment. 1 to 7, FIG. 7 is described on the premise that steps S601 to S608 are performed in advance.

In step S701, the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink.

In step S702, the WFD sink may transmit an RTSP M5 response message to the WFD source in response to the RTSP SET parameter request message.

In step S703, if the RTSP M5 message including the trigger parameter setting (SETUP) is exchanged successfully, the WFD sink may transmit the RTSP SETUP request message (RTSP M6 request) to the WFD source.

In step S704, if the RTSP M6 request message is received, the WFD source may transmit a RTSP SETUP response message (RTSP M6 response) to the WFD sink. For example, the establishment of a status code included in the RTSP M6 response message may indicate successful establishment of the RTSP session.

In step S705, after the successful exchange of the RTSP M6 message, the WFD sink may transmit an RTSP PLAY request message (RTSP M7 request message) to the WFD source to inform that it is ready to receive the RTP stream.

In step S706, the WFD source may transmit an RTSP PLAY response message to the WFD sink.

For example, successful establishment of the WFD session may be indicated based on the status code included in the RTSP PLAY response message.

After the WFD session has been established, the WFD source can be used to update the RTSP M3 request message (RTSP GET_PARAMETER request message) to obtain the capability of at least one RTSP parameter supported by the WFD sink to the WFD sync, and to update the audio / video format. RTSP M4 request message to set at least one RTSP parameter value corresponding to the WFD session for capability renegotiation between the WFD source and the WFD sink, RTSP triggering the WFD sink to send an RTSP PAUSE request message (RTSP M9 request message) M5 request message, RTSP M12 request message indicating that the WFD source enters WFD standby mode, RTSP M14 request message to select input type, input device and other parameters to be used in user input back channel (UIBC). Alternatively, an RTSP M15 request message for enabling or disabling a user input back channel (UIBC) may be transmitted to the WFD sink. .

The WFD sink receiving the aforementioned RTSP request message from the WFD source may respond with an RTSP response message.

Subsequently, the WFD Sink may request an RTSP M7 request message (RTSP PLAY request message) to start (or resume) audio / video streaming, or an RTSP M9 request message (to suspend audio / video streaming from the WFD source to the WFD sink). RTSP PAUSE request message), RTSP M10 request message to request the WFD source to change the audio rendering device, RTSP M11 request message to instruct to change the active connector type, WFD sink has entered WFD standby mode. RTSP M12 request message indicating the message, M13 request message requesting the WFD source to refresh instantaneous decoding refresh (IDR), RTSP M14 request message to select the input type to be used in UIBC, input device and other parameters or activation of UIBC. RTSP M15 request messages for enable or disable can be sent to the WFD source. .

The WFD source receiving the above-listed RTSP request message from the WFD sink may respond with an RTSP response message.

Once the WFD session is established and audio / video streaming starts, the WFD source and the WFD sink can proceed with audio / video streaming using a codec that they both support. By using a codec commonly supported by the WFD source and the WFD sink, interoperability between the two can be guaranteed.

8 shows an application example based on the connection according to the MA-USB according to the present embodiment.

According to the present embodiment of FIG. 8, the wired connection between the wireless devices connected with the conventional USB cable may be replaced with a wireless connection.

For example, the first wireless device 810 of FIG. 10 may be a WFD source, and the second wireless device 820 may be understood as a WFD sink.

The first wireless device 810 may perform screen mirroring with the second wireless device 820 based on the WFD connection. In addition, the first wireless device 810 may perform settings for MTP (Media Transfer Protocol) connection to the second wireless device 820. For example, the MTP connection may be implemented based on MA-USB.

When the MTP connection is completed between the first wireless device 810 and the second wireless device 820, the first wireless device 810 may import a media file of the second wireless device 820 based on the MTP connection. . In addition, the first wireless device 810 may export the media file of the first wireless device 810 to the second wireless device 820 based on the MTP connection.

The device type of the wireless device performing the connection according to the MA-USB may be a "device" type, a "hub" type, or a "host" type.

For example, the device type of the first wireless device 810 that performs the connection according to the MA-USB may be a 'device' type. The device type of the second wireless device 820 that performs the connection according to the MA-USB may be a 'host' type.

It will be understood that the wireless device is described herein on the premise that it supports both WFD connection and connection according to MA-USB. In addition, in the present specification, the MA-USB and Wi-Fi serial bus (hereinafter, 'WSB') may be used interchangeably with the same meaning.

9 to 10 illustrate a WFD connection procedure according to the present embodiment.

The first wireless device 910 of FIGS. 9 to 10 may be understood as a WFD source, and the second wireless device 920 may be understood as a WFD sink. The first wireless device 910 may search for the second wireless device 920 supporting WFD based on mDNS / DNS-SD. The first wireless device 910 may establish a connection with the second wireless device 920 that supports WFD through the AP 930. The AP 930 may receive a signal from the first wireless device 910 and transmit the received signal to the second wireless device 920. The AP 930 may receive a signal from the second wireless device 920 and transmit the received signal to the first wireless device 910.

In detail, the first wireless device 910 may transmit an mDNS query message to the second wireless device 920 to identify whether the second wireless device 920 supports WFD. The mDNS query message may include information for requesting whether the second wireless device 920 supports WFD. The second wireless device 920 may identify whether the second wireless device 920 supports WFD based on the mDNS query message. The second wireless device 920 may transmit an mDNS response message to the first wireless device 910. The mDNS response message may include information about whether the second wireless device 920 supports WFD and supporting WFD service (eg, WFD source, WFD sink). The first wireless device 910 may search for a second wireless device supporting WFD, and then establish a WFD connection. The first wireless device 910 or the second wireless device 920 may trigger a MA-USB connection after the WFD connection. The first wireless device 910 or the second wireless device 920 may search for MA-USB support and perform a MA-USB connection procedure.

The present specification describes a search for MA-USB support and a MA-USB connection procedure through a signal according to WFD in a wireless device. 10 to 16 illustrate a method of negotiating MA-USB capability information together in a WFD capability negotiation process. FIG. 17 illustrates a method of searching whether a wireless device supporting WFD supports MA-USB using an mDNS service discovery procedure. FIG. 18 illustrates a method of searching for whether to support MA-USB service through a probe request message and a probe response message before the mDNS service discovery procedure.

9 to 10 illustrate that the first wireless device 910 and the second wireless device 920 transmit signals through the AP 930, but are not limited thereto. The first wireless device 910 and the second wireless device 920 may transmit a signal through a peer to peer (P2P) connection without an AP. The following drawings also illustrate that the first wireless device and the second wireless device transmit signals through the AP, but are not limited thereto. The first wireless device and the second wireless device may transmit a signal through a peer to peer (P2P) connection without an AP.

11 illustrates a procedure of negotiating MA-USB capability information according to the present embodiment.

The first wireless device 1110 of FIG. 11 may be understood as a WFD source, and the second wireless device 1120 may be understood as a WFD sink. The first wireless device 1110 and the second wireless device 1120 may establish a connection through the AP 1130. The first wireless device 1110 may transmit a signal (or message) to the second wireless device 1120 through the AP 1130. The second wireless device 1110 may transmit a signal (or message) to the second wireless device 1120 through the AP 1130.

Although not shown in FIG. 11, a WFD device discovery procedure may be performed between the first wireless device 1110 and the second wireless device 1120. The WFD device discovery procedure may correspond to step S401 shown in FIG. 4.

Although not shown in FIG. 11, FIG. 11 shows an RTSP M1 request message, an RTSP M1 response message, an RTSP M2 request message, and / or an RTSP M2 response message as shown in FIG. 6. It is described on the premise that they are exchanged in advance between 1120.

In operation S1110, the first wireless device 1110 may transmit an RTSP M3 request message to the second wireless device 1120. The RTSP M3 request message of FIG. 11 may include an RTSP GET_PARAMETER Request.

The RTSP M3 request message may be used to query the attributes and capabilities of the second wireless device 1120, which is a WFD sink.

In addition, in order to request capability information for a Media Agnostic Universal Serial Bus (MA-USB) of the second wireless device 1120, the RTSP M3 request message according to the present embodiment includes mausb-capability information as shown in Table 1 below. can do.

In operation S1120, the first wireless device 1110 may receive an RTSP M3 response message from the second wireless device 1120 in response to the RTSP M3 request message. The RTSP M3 response message of FIG. 11 may include an RTSP GET_PARAMETER Response.

That is, the RTSP M3 response message may be used to convey information about attributes and capabilities of the second wireless device 1120 that is the WFD sink to the first wireless device 1110.

In this case, the RTSP M3 response message may include information corresponding to at least one field according to the request of the first wireless device 1110 among the plurality of fields shown in Table 1. That is, the RTSP M3 response message may include capability information for the MA-USB of the second wireless device 1120.

For example, the RTSP M3 response message may include information about the device type of the second wireless device 1120 and / or information about the transportMode of the second wireless device 1120. The information on the transportMode may include information indicating one of IP-based communication or MAC-based communication.

Subsequently, the first wireless device 1110 is based on the capability information for its MA-USB and / or the capability information for the MA-USB of the second wireless device 1120. The setting parameter for the connection according to the MA-USB between the wireless devices 1120 may be determined.

In operation S1130, the first wireless device 1110 may transmit an RTSP M4 request message including first operation information about configuration parameters for connection according to the MA-USB to the second wireless device 1120. The RTSP M4 request message of FIG. 11 may include an RTSP SET_PARAMETER Request.

In addition, the RTSP M4 request message may further include second operation information for notifying that the connection according to the MA-USB will be enabled. For example, the second operation information may include mausb-setting information.

For example, the mausb-setting information may be used to inform the state of the connection according to the MA-USB of the second wireless device 1120 as 'disable' or 'enable'. For clear and concise understanding of FIG. 11, it can be assumed that mausb-setting information is set to 'enable'.

In operation S1140, the first wireless device 1110 may receive an RTSP M4 response message from the second wireless device 1120 in response to the RTSP M4 request message. The RTSP M4 response message of FIG. 11 may include RTSP SET_PARAMETER Response.

For example, the RTSP M4 response message may include information indicating that the first operation information and the second operation information are accepted by the second wireless device 1120.

When steps S1110 to S1140 of FIG. 11 are performed, a procedure for negotiating capabilities for connection according to MA-USB between the first wireless device 1110 and the second wireless device 1120 may be completed.

Although not shown in FIG. 11, after the steps S1110 to S1140 of FIG. 11 are performed, the procedure of FIG. 7 may be performed to establish a WFD session between the first wireless device 1110 and the second wireless device 1120. . That is, if a WFD session between the first wireless device 1110 and the second wireless device 1120 is established, an AV stream may be transmitted.

According to the present embodiment, the screen of the first wireless device 1110 may be screen mirrored on the second wireless device 1120. In addition, the media file may be exchanged between the first wireless device 1110 and the second wireless device 1120 based on the MTP connection.

According to the present embodiment, through the MA-USB connection, not only screen mirroring but also media files can be exchanged in both directions. In order to establish a MA-USB connection, a MA-USB capability search may be performed.

12 illustrates a procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

Referring to FIG. 12, the WFD connection procedure may be performed based on the WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1130. The first wireless device 1210 may correspond to the first wireless device 1110 of FIG. 11. The second wireless device 1220 may correspond to the second wireless device 1120 of FIG. 11. The AP 1230 may correspond to the AP 1130 of FIG. 11.

In operation S1210, the first wireless device 1210 may transmit an M28 request message for requesting connection according to MA-USB to the second wireless device 1220 through the AP 1230. The M28 request message may include RTSP SET_PARAMETER Request, which is a message for requesting MA-USB data path setting. The M28 request message may further include mausb-capability information.

In operation S1220, the second wireless device 1220 may transmit an M28 response message to the first wireless device 1210 through the AP 1230 in response to the M28 request message. The M28 response message may include RTSP SET_PARAMETER Response, which is a message for responding to the MA-USB data path setup. The M28 response message may further include result information on the connection request according to the MA-USB. For example, the result information may include success information for accepting a connection according to the MA-USB or failure information for rejecting the connection according to the MA-USB.

According to an embodiment of the present disclosure, an M28 request message for requesting a connection according to MA-USB may be transmitted regardless of a device type (ie, a host type, a device type, or a hub type). According to an embodiment of the present disclosure, an M28 request message for requesting connection according to MA-USB may be transmitted regardless of a source device or a sink device.

FIG. 13 illustrates another procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

Referring to FIG. 13, the WFD connection procedure may be performed based on the WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1330. The first wireless device 1310 may correspond to the first wireless device 1110 of FIG. 11. The second wireless device 1320 may correspond to the second wireless device 1120 of FIG. 11. The AP 1330 may correspond to the AP 1130 of FIG. 11.

In operation S1310, the first wireless device 1310 and the second wireless device 1320 may perform a WFD session connection through the AP 1330. Step S1310 may correspond to a procedure for performing a WFD session connection shown in FIGS. 6 and 7. In operation S1310, the first wireless device 1310 and the second wireless device 1320 may search for capability information for the MA-USB through the RTSP M3 request message and the RTSP M3 response message. The searching of the capability information for the MA-USB through the RTSP M3 request message and the M3 response message may correspond to steps S1110 to S1120 of FIG. 11. If a WFD session is established between the first wireless device 1310 and the second wireless device 1320, an AV stream may be transmitted.

In operation S1320, the first wireless device 1310 may receive a user input for triggering a MA-USB connection. The first wireless device 1310 and the second wireless device 1320 may set a MA-USB data path through an RTSP M28 request message and an RTSP M28 response message in response to a user input for triggering a MA-USB connection. . That is, the first wireless device 1310 and the second wireless device 1320 may establish a MA-USB connection through an RTSP M28 request message and an RTSP M28 response message in response to a user input for triggering a MA-USB connection. Can be. Step S1320 may correspond to steps S1210 to S1220 of FIG. 12.

In S1330, when the IP transport for the first wireless device 1310 and the second wireless device 1320 is TCP for data exchange based on the MA-USB, the first wireless device 1310 and the second wireless device ( 1320 may perform a TCP connection establishment process.

For example, a wireless device with the role of a MA-USB device (ie, a TCP connection initiator) can forward TCP SYN packets to a wireless device with the role of a MA-USB host.

Subsequently, the wireless device having the role of the MA-USB host receiving the TCP SYNC packet may forward the TCP SYN-ACK packet to the wireless device having the role of the MA-USB device.

Subsequently, the wireless device having the role of the MA-USB device receiving the TCP SYN-ACK packet may transmit the ACK to the wireless device having the role of the MA-USB host to complete the TCP connection.

The 3-way handshake process for the TCP connection can be performed based on the negotiated TCP port based on the mausb-capability information in Table 1.

When the connection according to the MA-USB and the TCP connection are established, data exchange according to the MA-USB may be enabled between the first wireless device 1310 and the second wireless device 1320.

An example of FIG. 13 is described between a MA-USB device and a MA-USB host, but it is to be understood that the present specification is not limited thereto. That is, as another example, the same process may be applied to the TCP connection between the MA-USB device and the MA-USB hub.

14 illustrates another procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

Referring to FIG. 14, the WFD connection procedure may be performed based on the WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1430. The first wireless device 1410 of FIG. 14 may correspond to the first wireless device 1110 of FIG. 11. The second wireless device 1420 of FIG. 14 may correspond to the second wireless device 1120 of FIG. 11. The AP 1430 of FIG. 14 may correspond to the AP 1130 of FIG. 11.

In FIG. 13, the first wireless device 1310 (that is, the WFD source) requests the second wireless device 1310 (ie, the WFD sink) to set the MA-USB data path through the RTSP M28 request message. FIG. 14 illustrates a procedure in which the second wireless device 1420 (ie, a WFD sink) requests a MA-USB data path setting from the first wireless device 1410 (ie, a WFD source) through an RTSP M27 request message. can do.

In operation S1410, the first wireless device 1410 and the second wireless device 1420 may establish a WFD session connection through the AP 1430. Step S1410 may correspond to step S1310 of FIG. 13.

In operation S1420, the second wireless device 1420 may receive a user input for triggering a MA-USB connection. The second wireless device 1420 may transmit an RTSP M27 request message to the first wireless device 1410 in response to a user input for triggering a MA-USB connection. The RTSP M27 request message may include an M27 GET_PARAMETER request message for requesting whether to support MA-USB. The second wireless device 1420 may be in a state of not identifying capability information of the first wireless device 1410. Accordingly, the second wireless device 1420 may request capability information of the first wireless device 1410 through the RTSP M27 request message.

The RTSP M28 request message illustrated in FIG. 13 may be a message for requesting capability information of the first wireless device 1310 (ie, WFD source) of the second wireless device 1320 (ie, WFD sink). Accordingly, the second wireless device 1420 (ie, WFD sink) may send an M27 request message to the first wireless device 1410 for requesting capability information of the first wireless device 1410 (ie, WFD source). Can be.

In operation S1430, the first wireless device 1410 may transmit an MTSP M27 response message to the second wireless device 1420. The RTSP M27 response message may include an M27 GET_PARAMETER response message for requesting whether MA-USB is supported. The RTSP M27 response message may include capability information of the first wireless device 1410 requested by the second wireless device 1420. For example, the RTSP M27 response message may include mausb-capability information of the first wireless device 1410. The second wireless device 1420 may receive an RTSP M27 response message from the first wireless device 1410 and obtain capability information of the first wireless device 1410.

In operation S1440, the first wireless device 1410 and the second wireless device 1420 may set the MA-USB data path through the RTSP M28 request message and the RTSP M28 response message. That is, the first wireless device 1410 and the second wireless device 1420 may establish a MA-USB connection through the RTSP M28 request message and the RTSP M28 response message. Operation S1440 may correspond to operations S1320 to S1330 of FIG. 13.

FIG. 15 illustrates another procedure of establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.

Referring to FIG. 15, the WFD connection procedure may be performed based on the WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1530. The first wireless device 1510 of FIG. 15 may correspond to the first wireless device 1110 of FIG. 11. The second wireless device 1520 of FIG. 15 may correspond to the second wireless device 1120 of FIG. 11. The AP 1530 of FIG. 15 may correspond to the AP 1130 of FIG. 11.

The first wireless device 1510 and the second wireless device 1520 may perform only a WFD session connection and establish a MA-USB connection without performing a WFD service. In detail, the first wireless device 1510 and the second wireless device 1520 may perform a WFD session connection by performing only an RTSP M1 message to an RTSP M4 message exchange procedure. The first wireless device 1510 and the second wireless device 1520 may not perform an RTSP M5 message to RTSP M7 message exchange procedure for performing a WFD service (eg, a streaming service). The first wireless device 1510 and the second wireless device 1520 may establish a MA-USB connection through the RTSP M28 message exchange procedure without performing the WFD service. Steps S1510 to S1530 illustrate operations of the first wireless device 1510 and the second wireless device 1520 for performing the MA-USB connection procedure.

In operation S1510, the first wireless device 1510 and the second wireless device 1520 may perform a WLAN Infrastructure based search spelling, an RTSP M1 message (eg, an RTSP M1 request message, and / or to perform a WFD session connection procedure). RTSP M1 response message) exchange procedure and RTSP M2 message (eg, RTSP M2 request message and / or RTSP M2 response message) exchange procedure. Step S1510 may correspond to steps S601 to S603 of FIG. 6.

In operation S1520, the first wireless device 1510 and the second wireless device 1520 may perform a procedure for negotiating (or searching for) MA-USB capability information. The first wireless device 1510 and the second wireless device 1520 are configured with an RTSP M3 message (eg, an RTSP M3 request message and / or an RTSP M3 response message) and an RTSP M4 message (eg, an RTSP M4 request message and And / or RTSP M4 response messages). When step S1520 is completed, the first wireless device 1510 and the second wireless device 1520 may complete the WFD session connection. Step S1520 may correspond to steps S1110 to S1140 of FIG. 11.

In operation S1530, the first wireless device 1510 and the second wireless device 1520 may perform a MA-USB connection procedure. Operation S1530 may correspond to operation S1320 to operation S1330 of FIG. 13.

16 illustrates another procedure of establishing a MA-USB connection based on a WFD connection procedure according to the present embodiment.

Referring to FIG. 16, the WFD connection procedure may be performed based on the WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1630. The first wireless device 1610 of FIG. 16 may correspond to the first wireless device 1110 of FIG. 11. The second wireless device 1620 of FIG. 16 may correspond to the second wireless device 1120 of FIG. 11. The AP 1630 of FIG. 16 may correspond to the AP 1130 of FIG. 11.

The first wireless device 1610 and the second wireless device 1620 may establish only a WFD session connection and establish a MA-USB connection without performing a WFD service. In detail, the first wireless device 1610 and the second wireless device 1620 may perform a WFD session connection by performing only an RTSP M1 message to an RTSP M4 message exchange procedure. The first wireless device 1610 and the second wireless device 1620 may not perform an RTSP M5 message to an RTSP M7 message exchange procedure for performing a WFD service (eg, a streaming service). The first wireless device 1610 and the second wireless device 1620 establish a MA-USB connection through an RTSP M27 message and / or RTSP M28 message exchange procedure without performing a WFD service (eg, streaming service). can do. Steps S1610 to S1630 illustrate operations of the first wireless device 1610 and the second wireless device 1620 for performing the MA-USB connection procedure.

In FIG. 15, the first wireless device 1510 (ie, the WFD source) requests the second wireless device 1520 (ie, the WFD sink) to set up the MA-USB data path through the RTSP M28 request message. FIG. 16 illustrates a procedure in which a second wireless device 1620 (that is, a WFD sink) requests a first wireless device 1610 (ie, a WFD source) to set up a MA-USB data path through an RTSP M27 request message. can do.

In operation S1610, the first wireless device 1610 and the second wireless device 1620 may establish a WFD session connection through the AP 1630. Step S1610 may correspond to step S1310 of FIG. 13.

In operation S1620, the first wireless device 1610 and the second wireless device 11620 may use an RTSP M27 message (eg, an RTSP M27 request message and / or an RTSP to negotiate (or retrieve) MA-USB capability information). M27 response message) can perform the exchange procedure. For example, the second wireless device 1620 may receive a user input for triggering a MA-USB connection. In response to the user input, the second wireless device 1620 may transmit an M27 request message to the first wireless device 1610. The first wireless device 1610 may transmit an M27 response message to the second wireless device in response to the M27 request message. That is, the second wireless device 1620 may identify whether the first wireless device 1610 supports the MA-USB through an RTSP M27 message exchange procedure. Operation S1620 may correspond to operation S1420 to operation S1430 of FIG. 14.

In operation S1630, the first wireless device 1610 and the second wireless device 1620 may perform a MA-USB connection procedure. Operation S1630 may correspond to operation S1320 to operation S1330 of FIG. 13.

10 to 16 illustrate a method of negotiating MA-USB capability information together in a WFD capability negotiation process, the wireless device (eg, the first wireless device or the second wireless device) may use the mDNS service discovery procedure or the like. It is possible to search whether the MA-USB service is supported before the mDNS service discovery procedure. FIG. 17 illustrates a method of searching whether a wireless device supporting WFD supports MA-USB using an mDNS service discovery procedure. FIG. 18 illustrates a method of searching for whether to support MA-USB service through a probe request message and a probe response message before the mDNS service discovery procedure.

According to various embodiments of the present disclosure, the WFD device may discover whether neighboring WFD devices support the WFD service through mDNS service discovery. A WFD device (hereinafter, referred to as a first WFD device) that detects whether or not the peripheral WFD devices support the WFD service may transmit an mDNS query message to the peripheral WFD devices. The mDNS query message may include a Service Instance Name. For example, the first WFD device may set the Service Instance Name to “_display._tcp.local”. Whether the WFD device receiving the mDNS query message (hereinafter referred to as the second WFD device) matches the Service Instance Name (ie, “_display._tcp.local”) included in the mDNS query message and the service supported by the second WFD device. You can check. When the second WFD device matches the Service Instance Name (ie, “_display._tcp.local”) included in the mDNS query message and the service supported by the second WFD device, the second WFD device sends an mDNS response message to the first WFD. Can send to the device. The mDNS response message may include a Service Instance Name. For example, when the second WFD device is a WFD sink, the second WFD device may set the Service Instance Name to “sink_display._tcp.local”.

According to various embodiments of the present disclosure, the WFD device may set a Service Instance Name including information related to the MA-USB service so that the WFD device may also search for the MA-USB service through an mDNS query message. . The information related to the MA-USB service may include information related to whether the MA-USB host service, the MA-USB device service, and the MA-USB hub service are supported. Information related to the MA-USB service may be related to the device type of the WFD device. For example, a WFD device supporting a MA-USB host service may have a device type of which is a host type.

When the Service Instance Name is set to “_display._tcp.local”, “_display._tcp.local” may include information about the main service type. The service instance name may further include information about the subtype service. The subtype service may include a MA-USB service. For example, if the Service Instance Name is set to “_mausb._sub._display._tcp.local”, then “_mausb._sub._display._tcp.local” contains information that supports the MA-USB service while supporting the WFD service. can do.

A WFD device (hereinafter, referred to as a first WFD device) that detects whether neighboring WFD devices support the WFD service, may set a service instance name to “_mausb._sub._display._tcp.local”. The first WFD device may transmit an mDNS query message including the Service Instance Name set to “_mausb._sub._display._tcp.local” to the second WFD device.

The second WFD device may check whether the Service Instance Name (ie, “_display._tcp.local”) included in the mDNS query message matches the service supported by the second WFD device. If the second WFD device matches the Service Instance Name (ie, “_display._tcp.local”) included in the mDNS query message and the service supported by the second WFD device, the second WFD device sends an mDNS response message to the first WFD. Can send to the device. The mDNS response message may include a Service Instance Name.

For example, when the second WFD device supports the MA-USB host service, the second WFD device may set the Service Instance Name to “_host_mausb._sub._display._tcp.local”. When the Service Instance Name is set to “_host_mausb._sub._display._tcp.local”, the Service Instance Name may include information that the second WFD device supports the MA-USB host service as a subtype service. That is, the first WFD device that receives the mDNS response message including “_host_mausb._sub._display._tcp.local” may identify that the second WFD device supports the WFD service and also supports the MA-USB host service. .

For another example, when the second WFD device supports the MA-USB device service, the second WFD device may set the Service Instance Name to “_device_mausb._sub._display._tcp.local”. If the Service Instance Name is set to “_device_mausb._sub._display._tcp.local”, the Service Instance Name may include information that the second WFD device supports the MA-USB device service as a subtype of service. That is, the first WFD device that receives the mDNS response message including “_device_mausb._sub._display._tcp.local” may identify that the second WFD device supports WFD service and also supports MA-USB device service. .

For another example, if the WFD device sending the mDNS response message supports the MA-USB hub service, the second WFD device should set the Service Instance Name to “_hub_mausb._sub._display._tcp.local”. Can be. If the Service Instance Name is set to “_hub_mausb._sub._display._tcp.local”, the Service Instance Name may include information that the WFD device supports the MA-USB hub service as a subtype of service. That is, the first WFD device that receives the mDNS response message including “_hub_mausb._sub._display._tcp.local” may identify that the second WFD device supports the WFD service and also supports the MA-USB hub service. .

In other words, “_mausb._sub” which is a service property of a subtype of the WFD service may be defined in the present specification. Accordingly, the first WFD device may identify whether the second WFD device supports the MA-USB service. In addition, the first WFD device may identify whether the second WFD device supports the MA-USB host service, the MA-USB device service, and / or the MA-USB hub service.

The operation of identifying whether the MA-USB service is supported may be performed regardless of whether the first wireless device is a WFD source or a WFD sink. For example, the WFD source may transmit an mDNS query message to the WFD sink device to identify whether the WFD sink supports the MA-USB service. In addition, the WFD sink device may transmit an mDNS query message to the WFD source device to identify whether the WFD source device supports the MA-USB service. That is, both the WFD source device and the WFD sink device may transmit an mDNS query message for identifying whether the counterpart WFD device supports the MA-USB service to the counterpart WFD device.

FIG. 17 illustrates a procedure of searching for support of a MA-USB service using mDNS Service Discovery.

Referring to FIG. 17, the WFD connection procedure may be performed based on WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1730. The first wireless device 1710 of FIG. 17 may be understood as a WFD source, and the second wireless device 1720 may be understood as a WFD sink. The first wireless device 1710 and the second wireless device 1720 may establish a connection through the AP 1730. The first wireless device 1710 may transmit a signal (or message) to the second wireless device 1720 through the AP 1730. The second wireless device 1710 can transmit a signal (or message) to the second wireless device 1720 through the AP 1730.

The first wireless device 1710 may transmit (or multicast) an mDNS query message. The second wireless device 1720 may receive an mDNS query message from the first wireless device 1710.

According to an embodiment of the present disclosure, the second wireless device 1720 receiving the mDNS query message determines whether a service supported by the second wireless device 1720 matches a Service Instance Name included in the mDNS query message. Can be identified. When the service supported by the second wireless device 1720 and the service instance name included in the mDNS query message match, the second wireless device 1720 may transmit an mDNS response message to the first wireless device 1710. .

For example, the second wireless device 1720 may support a WFD sink service and a MA-USB host service. The second wireless device 1720 may set the Service Instance Name to “_host_mausb._sub._sink._display._tcp.local” to transmit an mDNS response message to the first wireless device 1710. The first wireless device 1710 may identify that the second wireless device 1720 supports a WFD sink service and a MA-USB host service through an mDNS response message.

18 illustrates a MA-USB service discovery procedure through probe request message and probe response message exchange.

Referring to FIG. 18, the WFD connection procedure may be performed based on WLAN infrastructure. For example, a signal for WFD connection may be transmitted or received via the AP 1830. The first wireless device 1810 of FIG. 18 may correspond to the first wireless device 1510 of FIG. 15. The second wireless device 1820 of FIG. 18 may correspond to the second wireless device 1520 of FIG. 15. The AP 1830 of FIG. 18 may correspond to the AP 1530 of FIG. 15.

FIG. 18 illustrates that MA-1 of the second wireless device 1820 may exchange the probe request message and the probe response message with the second wireless device 1820 before the mDNS query message and the mDNS response message exchange. A method of identifying whether or not a USB service is supported is illustrated.

The probe request message and / or probe response message may include a vendor extension attribute. Vendor Extension Attribute may include attribute information according to the Wi-Fi Simple Configuration standard. The vendor extension attribute may further include a MA-USB service attribute as a subelement.

The MA-USB service attribute may include an Attributeid field, a Length field, and / or a MausbInfo field. The Attributeid field may include information about a 2-byte MA-USB attribute ID. The Length field may include information about the length of a 2-byte MausbInfo field. The MausbInfo field may include 1 byte of information. The MausbInfo field may include a MAUSB support bit (1 bit), a Host service bit (1 bit), a Device service bit (1 bit), a Hub service bit (1 bit), and / or a Reserved bit (4 bit).

The MAUSB support bit may include information on whether MAUSB is supported. For example, the MAUSB support bit may have a first value (eg, {1}) when the MAUSB service is supported. The MAUSB support bit may have a second value (eg, {0}) when it does not support the MAUSB service.

The host service bit may include information on whether to support the MA-USB host service when the MAUSB is supported. For example, the host service bit may have a first value (eg, {1}) when the MA-USB host service is supported. The host service bit may have a second value (eg, {0}) when the MA-USB host service is not supported.

If the device service bit supports MAUSB, the device service bit may include information on whether to support a MA-USB device service. For example, the device service bit may have a first value (eg, {1}) when the MA-USB device service is supported. The device service bit may have a second value (eg, {0}) when the MA-USB device service is not supported.

The hub service bit may include information on whether to support the MA-USB hub service when the MAUSB is supported. For example, the Hub service bit may have a first value (eg, {1}) when the MA-USB hub service is supported. The hub service bit may have a second value (eg, {0}) when the MA-USB hub service is not supported.

In operation S1810, the first wireless device 1810 may transmit a probe request message to the second wireless device 1820. The probe request message may include a vendor extension attribute. The first wireless device 1810 may request (or search) whether the second wireless device 1820 supports the MA-USB through a probe request message. In addition, if the second wireless device 1820 supports the MA-USB through the probe request message, the first wireless device 1810 supports the MA-USB host service, whether the MA-USB device service is supported, and / Or, it may request (or search) whether the MA-USB hub service is supported.

In operation S1820, the second wireless device 1820 may transmit a probe response message to the first wireless device 1810. The probe response message may include a vendor extension attribute. The second wireless device 1820 may transmit information on whether the second wireless device 1820 supports the MA-USB to the first wireless device 1810 through the MA-USB Attribute included in the Vendor Extension Attribute. In addition, if the second wireless device 1820 supports the MA-USB, the second wireless device 1820 supports the MA-USB host service, whether the MA-USB device service is supported, and / or the MA-USB hub. Whether to support the service may be transmitted to the first wireless device 1810 through the MA-USB Attribute.

In operation S1830, the first wireless device 1810 may transmit an mDNS Query message to the second wireless device 1820. The second wireless device 1820 may transmit an mDNS response message to the first wireless device 1810.

The first wireless device 1810 (ie, the WFD source) requests the second wireless device 1820 (ie, the WFD sink) to support the MA-USB service of the second wireless device 1820 through a probe request message. Steps are shown, but are not limited to such. The second wireless device 1820 (ie, the WFD sink) may transmit a probe request message to the first wireless device 1810 (ie, the WFD source). The second wireless device 1820 may request whether the first wireless device 1810 supports the MA-USB service through a probe request message.

According to an embodiment, a vendor extension attribute including a MA-USB service attribute may be included in a beacon message. The first wireless device 1810 may transmit information on whether to support the MA-USB service to the second wireless device 1820 through a beacon message.

19 is a diagram illustrating an operation of a wireless device to which an example of the present specification is applied.

In operation S1910, the first wireless device (eg, the first wireless device 1710 of FIG. 17) is a WLAN display service of the second wireless device (eg, the second wireless device 1720 of FIG. 17). And an mDNS Query message for requesting whether to support the MA-USB service to the second wireless device. The WLAN display service may include a WFD service. The mDNS query message may include a Service Instance Name.

For example, the first wireless device may set the Service Instance Name to “_mausb._sub._display._tcp.local” to transmit to the second wireless device. “_Mausb._sub._display._tcp.local” may include information that supports the WLAN display service and at the same time supports the MA-USB service.

The second wireless device can identify whether the service instance name included in the mDNS query message matches the service supported by the second wireless device. For example, if the Service Instance Name is set to “_mausb._sub._display._tcp.local”, the second wireless device indicates that the first wireless device supports the WLAN display service and supports the MA-USB service. Can be identified. The second wireless device may identify whether the WLAN display service supported by the first wireless device and the MA-USB service match the service supported by the second wireless device.

In operation S1920, in response to the mDNS query message, the first wireless device relates to information about the first mode of the second wireless device related to the WLAN display service and to the second mode of the second wireless device related to the MA-USB service. An mDNS response message including the information may be received from the second wireless device.

The information about the first mode of the second wireless device related to the WLAN display service may include an operation mode according to whether the second wireless device supports the WLAN display service. Information regarding the second mode of the second wireless device related to the MA-USB service may be obtained by operating mode according to whether the MA-USB host service is supported, whether the MA-USB device service is supported, and / or whether the MA-USB hub service is supported. It may include. That is, the information about the second mode of the second wireless device related to the MA-USB service may include information about the type of the second wireless device. For example, the second mode of the second wireless device related to the MA-USB service may include at least one of a host type, a device type, and / or a hub type.

In detail, when the second wireless device matches the service instance name included in the mDNS query message and a service supported by the second wireless device, the second wireless device may transmit an mDNS response message to the first wireless device. The mDNS response message may include a Service Instance Name. The service instance name may include information on whether the WLAN display service is supported and / or whether the MA-USB service is supported. In addition, the Service Instance Name further includes information on whether the MA-USB host service is supported, whether the MA-USB device service is supported, and / or whether the MA-USB hub service is supported, if the MA-USB service is supported. can do. For example, the second wireless device may set the Service Instance Name to “_host_mausb._sub._display._tcp.local” to transmit to the first wireless device. “_Host_mausb._sub._display._tcp.local” may include information indicating that the WLAN display service is supported and the MA-USB host service is also supported.

In operation S1930, the first wireless device identifies information on the first mode of the second wireless device related to the WLAN display service and the second mode of the second wireless device related to the MA-USB service, based on the mDNS response message. can do.

Additionally, the first wireless device is based on the information about the first mode of the second wireless device related to the WLAN display service and the information about the second mode of the second wireless device related to the MA-USB service. Determine a third mode of the first wireless device associated with and a fourth mode of the first wireless device associated with MA-USB service.

The information about the third mode of the first wireless device related to the WLAN display service may include an operation mode according to whether the first wireless device supports the WLAN display service. Information on the fourth mode of the first wireless device related to the MA-USB service may be obtained by operating mode according to whether the MA-USB host service is supported, whether the MA-USB device service is supported, and / or whether the MA-USB hub service is supported. It may include. That is, the information about the fourth mode of the first wireless device related to the MA-USB service may include information about the type of the first wireless device. For example, the fourth mode of the first wireless device related to the MA-USB service may include at least one of a host type, a device type, and / or a hub type.

For example, when the second wireless device supports the WLAN display service, the first wireless device may determine an operation mode for supporting the WLAN display service. When the second wireless device supports the MA-USB host service, the first wireless device may determine an operation mode for supporting the MA-USB device service. When the first wireless device and the second wireless device establish a WFD connection and a MA-USB connection, the first wireless device may operate in a third mode and a fourth mode. The second wireless device can operate in a first mode and a second mode.

20 is a block diagram illustrating a wireless device to which the present embodiment can be applied.

Referring to FIG. 20, the wireless device may be an STA or an AP or a non-AP STA that may implement the above-described embodiment. In addition, the wireless device may correspond to the above-described user, or may correspond to a transmitting terminal for transmitting a signal to the user.

The wireless device of FIG. 20 includes a processor 2010, a memory 2020 and a transceiver 2030 as shown. The processor 2010, the memory 2020, and the transceiver 2030 may be implemented as separate chips, or at least two blocks / functions may be implemented through one chip.

The transceiver 2030 is a device including a transmitter and a receiver. When a specific operation is performed, only one of the transmitter and the receiver may be performed, or both the transmitter and the receiver may be performed. have.

The transceiver 2030 may include one or more antennas for transmitting and / or receiving wireless signals. In addition, the transceiver 2030 may include an amplifier for amplifying a received signal and / or a transmitted signal and a bandpass filter for transmission on a specific frequency band.

The processor 2010 may implement the functions, processes, and / or methods proposed herein. For example, the processor 2010 may perform an operation according to the present embodiment described above. That is, the processor 2010 may perform the operations disclosed in the embodiments of FIGS. 1 to 19.

The processor 2010 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, a data processing device, and / or a converter for translating baseband signals and wireless signals.

The memory 2020 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage device.

21 is a block diagram illustrating an example of an apparatus included in a processor.

For convenience of description, an example of FIG. 21 is described based on a block for a transmission signal, but it is obvious that the reception signal can be processed using the block.

The illustrated data processing unit 2110 generates transmission data (control data and / or user data) corresponding to the transmission signal. The output of the data processor 2110 may be input to the encoder 2120. The encoder 2120 may perform coding through a binary convolutional code (BCC) or a low-density parity-check (LDPC) technique. At least one encoder 2120 may be included, and the number of encoders 2120 may be determined according to various information (eg, the number of data streams).

The output of the encoder 2120 may be input to the interleaver 2130. The interleaver 2130 performs an operation of distributing consecutive bit signals over radio resources (eg, time and / or frequency) to prevent burst errors due to fading or the like. At least one interleaver 2130 may be included, and the number of the interleaver 2130 may be determined according to various information (eg, the number of spatial streams).

The output of the interleaver 2130 may be input to a constellation mapper 2140. The constellation mapper 2140 performs constellation mapping such as biphase shift keying (BPSK), quadrature phase shift keying (QPSK), quadrature amplitude modulation (n-QAM), and the like.

The output of the constellation mapper 2140 may be input to the spatial stream encoder 2150. The spatial stream encoder 2150 performs data processing to transmit the transmission signal through at least one spatial stream. For example, the spatial stream encoder 2150 may perform at least one of space-time block coding (STBC), cyclic shift diversity (CSD) insertion, and spatial mapping on a transmission signal.

The output of the spatial stream encoder 2150 may be input to an IDFT 2160 block. The IDFT 2160 block performs an inverse discrete Fourier transform (IDFT) or an inverse Fast Fourier transform (IFFT).

The output of the IDFT 2160 block is input to the Guard Interval (GI) inserter 2170, and the output of the GI inserter 2170 is input to the transceiver 2030 of FIG. 20.

In the detailed description of the present specification, specific embodiments have been described, but various modifications are possible without departing from the scope of the present specification. Therefore, the scope of the present specification should not be limited to the above-described embodiments, but should be defined not only by the claims below but also by the equivalents of the claims of the present invention.

Claims (14)

1. In a WLAN system,

   The second wireless device sends a multicast domain name system (mDNS) query message for requesting whether the second wireless device supports the WLAN display service and the MA-USB (Media Agnostic Universal Serial Bus) service. Transmitting to a wireless device;

   The first wireless device, in response to the mDNS query message, information regarding the first operation mode of the second wireless device related to the WLAN display service and the second wireless device related to the MA-USB service; 2 receiving an mDNS response message from the second wireless device, the mDNS response message comprising information regarding an operation mode; And

   The first wireless device based on the mDNS response message, information regarding the first operation mode of the second wireless device related to the WLAN display service and the second wireless device related to the MA-USB service; 2 identifying a mode of operation,

   The mDNS query message and the mDNS response message is transmitted via an access point (AP).
2. The method of claim 1, wherein the information about the first operation mode of the second wireless device related to the wireless LAN display service includes:

   And information about an operation mode according to whether the second wireless device supports the WLAN display service.
3. The method of claim 2, wherein the information about the second operation mode of the second wireless device related to the MA-USB service is:

   And information about an operation mode according to whether the MA-USB service is supported.
4. According to claim 3, The operation mode according to whether the MA-USB service support,

   And a mode of operation according to at least one of a MA-USB host service, a MA-USB device service, or a MA-USB hub service.
5. The method of claim 1, wherein the MA-USB service,

   Supported method based on the WLAN display service.
6. According to claim 1,

   The first wireless device based on the information about the first mode of the second wireless device related to the WLAN display service and the information about the second mode of the second wireless device related to the MA-USB service; Determining a third mode of the first wireless device associated with the WLAN display service and a fourth mode of the first wireless device associated with the MA-USB service.
7. The method of claim 6,

   Performing, by the first wireless device, real time streaming protocol (RTSP) frame exchange with the second wireless device;

   Establishing, by the first wireless device, the connection for the WLAN display service based on the RTSP frame exchange; And

   Establishing, by the first wireless device, the connection for the MA-USB service after the connection for the WLAN display service is established.
8. In a first wireless device, the first wireless device,

   A transceiver for transmitting and receiving a radio signal; And

   A processor coupled to the transceiver, wherein the processor includes:

   A multicast domain name system (mDNS) query message for requesting whether the second wireless device supports the WLAN display service and the MA-USB (Media Agnostic Universal Serial Bus) service is transmitted to the second wireless device through the AP. and,

   In response to the mDNS query message, information about a first operation mode of the second wireless device related to the WLAN display service and information about a second operation mode of the second wireless device related to the MA-USB service. Receive, via the AP, an mDNS response message from the second wireless device,

   Based on the mDNS response message, set to identify information about a first operation mode of the second wireless device related to the WLAN display service and a second operation mode of the second wireless device related to the MA-USB service. Wireless device.
9. The method of claim 8, wherein the information about the first operation mode of the second wireless device related to the wireless LAN display service includes:

   Wireless device including information on the operation mode according to whether the second wireless device supports the WLAN display service.
10. 10. The method of claim 9, wherein the information about the second operation mode of the second wireless device related to the MA-USB service is:

    Wireless device including information on the operation mode according to whether the MA-USB service support.
11. The method of claim 10, wherein the operation mode according to whether the MA-USB service support,

    A wireless device comprising an operation mode according to at least one of a MA-USB host service, a MA-USB device service, or a MA-USB hub service.
12. The method of claim 8, wherein the MA-USB service,

    A wireless device supported based on the WLAN display service.
13. The method of claim 8, wherein the processor,

    Based on the information on the first mode of the second wireless device related to the WLAN display service and the information on the second mode of the second wireless device related to the MA-USB service, And determine a third mode of the first wireless device and a fourth mode of the first wireless device associated with the MA-USB service.
14. The method of claim 13, wherein the processor,

    Perform Real Time Streaming Protocol (RTSP) frame exchange with the second wireless device,

    The first wireless device establishes a connection for the WLAN display service based on the RTSP frame exchange;

    And configured to establish a connection for the MA-USB service after the first wireless device is established for the WLAN display service.

Images