WO2020022728A1 - Procédé de prise en charge de connexion de bus série universel agnostique par rapport au support (ma-usb), et dispositif sans fil utilisant celui-ci - Google Patents

Procédé de prise en charge de connexion de bus série universel agnostique par rapport au support (ma-usb), et dispositif sans fil utilisant celui-ci Download PDF

Info

Publication number
WO2020022728A1
WO2020022728A1 PCT/KR2019/009047 KR2019009047W WO2020022728A1 WO 2020022728 A1 WO2020022728 A1 WO 2020022728A1 KR 2019009047 W KR2019009047 W KR 2019009047W WO 2020022728 A1 WO2020022728 A1 WO 2020022728A1
Authority
WO
WIPO (PCT)
Prior art keywords
wireless device
service
usb
wfd
rtsp
Prior art date
Application number
PCT/KR2019/009047
Other languages
English (en)
Korean (ko)
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 WO2020022728A1 publication Critical patent/WO2020022728A1/fr

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 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.
  • 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.
  • 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.
  • mDNS mDNS
  • MA-USB Media Agnostic Universal Serial Bus
  • 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).
  • AP access point
  • a method for establishing a MA-USB connection and a wireless device using the same may be provided based on a WFD connection procedure.
  • FIG. 1 is an exemplary diagram illustrating a 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 illustrating a WFD session.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • FIG. 6 is a conceptual diagram showing a procedure for WFD capability exchange negotiation.
  • FIG. 7 is a conceptual diagram illustrating a procedure for establishing a WFD session.
  • FIG 8 shows an application example based on the connection according to the MA-USB according to the present embodiment.
  • FIG. 11 illustrates a procedure of negotiating MA-USB capability information according to the present embodiment.
  • FIG. 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.
  • FIG. 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.
  • FIG. 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.
  • FIG. 1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.
  • 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 may be a basic building block of an IEEE 802.11 LAN.
  • BSS Basic Service Set
  • BSS1 and BSS2 may exist 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 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.
  • BS base station
  • eNB Evolved Node-B
  • BTS Base Transceiver System
  • Femto base station in other wireless communication fields
  • 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.
  • WTRU wireless transmit / receive unit
  • UE user equipment
  • MS mobile station
  • MS mobile terminal
  • MSS Mobile Subscriber Station
  • 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).
  • BSA basic service area
  • IBS independent BSS
  • the IBSS may have a minimal form consisting of only two STAs.
  • 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.
  • 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.
  • 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.
  • Wi-Fi Direct 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.
  • WFD Wi-Fi Direct
  • WFD Wi-Fi Direct
  • Wi-Fi Direct 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.
  • P2P group owner 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.
  • P2P group owner hereinafter, 'P2P GO'
  • P2P clients may exist around P2P GO. Only one P2P GO can exist in one P2P group, and all other devices become client devices.
  • Wi-Fi Alliance provides various services using the Wi-Fi Direct link (e.g., Send, Play, Display, Print, etc.).
  • Wi-Fi Direct link e.g., Send, Play, Display, Print, etc.
  • WFDS Wi-Fi Direct Service
  • an application may be controlled or managed by an application service platform (hereinafter referred to as "ASP").
  • ASP application service platform
  • 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.
  • 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.
  • 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.
  • information about the WFD devices eg, capability information
  • a WFD session may be a network between a source device that provides content and a sink device that receives and renders the content.
  • the source device may be referred to as a WFD source.
  • 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.
  • an internet protocol (hereinafter, referred to as 'IP') address may be allocated for each of the WFD source and the WFD sink.
  • TCP transmission control protocol
  • RTSP real time streaming protocol
  • 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.
  • a data session via RTP may be established between the WFD source and the WFD sink.
  • User Datagram Protocol may be used for data transport in a WFD network.
  • FIG. 2 is an exemplary block diagram illustrating a WFD network.
  • 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).
  • a specific connection scheme eg, WiFi-P2P scheme.
  • the WFD source 200 of FIG. 2 may be a device that supports streaming of multimedia content through a P2P link.
  • 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.
  • the WFD sink 250 of FIG. 2 may be a primary sink or a secondary sink.
  • the secondary sync may render only the audio payload from the WFD source 200.
  • FIG. 3 is an exemplary conceptual diagram illustrating a WFD session.
  • 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.
  • the WFD source 320 may be connected with the primary sink 325 based on a video-only session.
  • the WFD source 340 may be connected to the primary sink 345 based on an audio and video session.
  • FIG. 3 a session connection according to a coupled WFD Sink operation is shown.
  • the primary sink 365 can render the video and the secondary sink 370 can render the audio.
  • primary sync 365 may render both video and audio.
  • 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.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • a WFD session may be established between the WFD source and the WFD sink.
  • the WFD source may perform a WFD device discovery procedure to find a peer device (ie, WFD sink) for the WFD.
  • a peer device ie, WFD sink
  • 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).
  • the WFD IE may include information associated with the WFD, such as a device type or a device state.
  • 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.
  • 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.
  • the probe response frame may include both a P2P IE and a WFD IE.
  • 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.
  • the WFD service discovery procedure may be an optional procedure.
  • 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.
  • the WFD device may select a WFD device (eg, WFD sink) for WFD connection setup.
  • a WFD device eg, a WFD sink
  • TDLS Tunneled Direct Link Setup
  • 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.
  • 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. Operation S404 will be described in more detail with reference to FIG. 6 to be described later.
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • the WFD source 500 may be connected to the 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 combined with a separate AP.
  • the source 550 may be connected to the WFD sink 560 based on the TDLS link.
  • the WFD source 550 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.
  • the WFD sink 560 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.
  • 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.
  • Wi-Fi Direct ie, P2P
  • TDLS link is used between the WFD source and the WFD sink
  • the WFD capability exchange and negotiation procedure may be performed after the WFD connection setup procedure between WFD devices.
  • 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).
  • RTSP Real Time Streaming Protocol
  • a set of parameters for defining the audio / video payload may be determined.
  • the WFD capability exchange and negotiation procedure may be performed by exchange of RTSP M1 to RTSP M4 messages.
  • FIG. 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.
  • the WFD source may send an RTSP M1 request message to start the RSTP procedure and WFD capability negotiation.
  • the RTSP M1 request message may include an RTSP OPTIONS Request.
  • the WFD sink may transmit an RTSP M1 response message in which the RTSP methods supported by the WFD sink are enumerated.
  • the RTSP M1 response message may include an RTSP OPTIONS Response.
  • the WFD sink may transmit an RTSP M2 request message for determining a 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 methods supported by the WFD source.
  • the RTSP M2 response message may include an RTSP OPTIONS Response.
  • 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.
  • 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 wants 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 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.
  • the WFD source may transmit an RTSP M4 request message including the determined parameter set to the WFD sink.
  • 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 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.
  • the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink.
  • RTSP M5 Trigger SETUP request an RTSP SET parameter request message
  • the WFD sink may transmit 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 exchanged successfully, the WFD sink may transmit the RTSP SETUP request message (RTSP M6 request) to the WFD source.
  • SETUP trigger parameter setting
  • the WFD source may transmit a RTSP SETUP response message (RTSP M6 response) to the WFD sink.
  • RTSP M6 response For example, the establishment of a status code included in the RTSP M6 response message may indicate successful establishment of the RTSP session.
  • 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.
  • RTSP M7 request message RTSP PLAY request message
  • the WFD source may transmit an RTSP PLAY response message to the WFD sink.
  • successful establishment of the WFD session may be indicated based on the status code included in the RTSP PLAY response message.
  • 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 M3 request message RTSP GET_PARAMETER request message
  • 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).
  • 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.
  • 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.
  • the WFD source and the WFD sink can proceed with audio / video streaming using a codec that they both support.
  • a codec commonly supported by the WFD source and the WFD sink, interoperability between the two can be guaranteed.
  • FIG 8 shows an application example based on the connection according to the MA-USB according to the present embodiment.
  • the wired connection between the wireless devices connected with the conventional USB cable may be replaced with a wireless connection.
  • the first wireless device 810 of FIG. 10 may be a WFD source
  • 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.
  • the first wireless device 810 may perform settings for MTP (Media Transfer Protocol) connection to the second wireless device 820.
  • MTP Media Transfer Protocol
  • the MTP connection may be implemented based on MA-USB.
  • the first wireless device 810 may import a media file of the second wireless device 820 based on the MTP connection. .
  • 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.
  • 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.
  • the wireless device is described herein on the premise that it supports both WFD connection and connection according to MA-USB.
  • the MA-USB and Wi-Fi serial bus (hereinafter, 'WSB') may be used interchangeably with the same meaning.
  • 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.
  • 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.
  • FIG. 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.
  • P2P peer to peer
  • 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.
  • P2P peer to peer
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • the RTSP M3 request message includes mausb-capability information as shown in Table 1 below. can do.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the RTSP M4 request message may further include second operation information for notifying that the connection according to the MA-USB will be enabled.
  • the second operation information may include mausb-setting information.
  • 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'.
  • the mausb-setting information is set to 'enable'.
  • 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.
  • 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.
  • steps S1110 to S1140 of FIG. 11 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.
  • 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.
  • the screen of the first wireless device 1110 may be screen mirrored on the second wireless device 1120.
  • the media file may be exchanged between the first wireless device 1110 and the second wireless device 1120 based on the MTP connection.
  • the MA-USB connection not only screen mirroring but also media files can be exchanged in both directions.
  • a MA-USB capability search may be performed.
  • FIG. 12 illustrates a procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.
  • the WFD connection procedure may be performed based on the WLAN infrastructure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a device type ie, a host type, a device type, or a hub type.
  • 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.
  • the WFD connection procedure may be performed based on the WLAN infrastructure.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first wireless device 1310 and the second wireless device 1320 may perform a TCP connection establishment process.
  • a wireless device with the role of a MA-USB device ie, a TCP connection initiator
  • 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.
  • 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.
  • data exchange according to the MA-USB may be enabled between the first wireless device 1310 and the second wireless device 1320.
  • FIG. 13 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.
  • FIG. 14 illustrates another procedure for establishing a MA-USB connection based on the WFD connection procedure according to the present embodiment.
  • the WFD connection procedure may be performed based on the WLAN infrastructure.
  • 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.
  • the first wireless device 1310 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the WFD connection procedure may be performed based on the WLAN infrastructure.
  • 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.
  • 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.
  • 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
  • RTSP M2 message eg, RTSP M2 request message and / or RTSP M2 response message
  • 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).
  • 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.
  • 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.
  • FIG. 16 illustrates another procedure of establishing a MA-USB connection based on a WFD connection procedure according to the present embodiment.
  • the WFD connection procedure may be performed based on the WLAN infrastructure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second wireless device 1620 may receive a user input for triggering a MA-USB connection.
  • 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.
  • 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.
  • FIG. 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
  • 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.
  • 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.
  • the first WFD device may set the Service Instance Name to “_display._tcp.local”.
  • the second WFD device 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.
  • 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.
  • the second WFD device is a WFD sink, the second WFD device may set the Service Instance Name to “sink_display._tcp.local”.
  • 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.
  • “_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.
  • the second WFD device may set the Service Instance Name 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. .
  • 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. .
  • 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. .
  • the first WFD device may identify whether the second WFD device supports the MA-USB service.
  • 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.
  • 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.
  • 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.
  • the WFD connection procedure may be performed based on WLAN infrastructure.
  • 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.
  • 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.
  • the second wireless device 1720 may transmit an mDNS response message to the first wireless device 1710. .
  • 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.
  • the WFD connection procedure may be performed based on WLAN infrastructure.
  • 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.
  • 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.
  • 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.
  • a first value eg, ⁇ 1 ⁇
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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
  • the second wireless device 1820 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the first wireless device in response to the mDNS query message, 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first wireless device may determine an operation mode for supporting the WLAN display service.
  • 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.
  • 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.
  • the wireless device may be an STA or an AP or a non-AP STA that may implement the above-described embodiment.
  • 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.
  • 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.
  • 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.
  • ASIC application-specific integrated circuit
  • the memory 2020 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage device.
  • ROM read-only memory
  • RAM random access memory
  • 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.
  • FIG. 21 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.
  • Radio resources eg, time and / or frequency
  • 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.
  • 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.
  • STBC space-time block coding
  • CSS cyclic shift diversity
  • 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).
  • IDFT inverse discrete Fourier transform
  • IFFT inverse Fast Fourier transform
  • 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.
  • GI Guard Interval

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un procédé de fonctionnement dans un système LAN sans fil, selon divers modes de réalisation de l'invention, comprend les étapes suivantes : permettre à un premier dispositif sans fil de transmettre, à un deuxième dispositif sans fil, un message d'interrogation de système de nom de domaine de multidiffusion (mDNS) pour demander si le deuxième dispositif sans fil prend en charge un service d'affichage LAN sans fil et un service de bus série universel agnostique par rapport au support (MA-USB); permettre au premier dispositif sans fil de recevoir, en provenance du deuxième dispositif sans fil, un message de réponse de mDNS contenant des informations sur un premier mode de fonctionnement, du deuxième dispositif sans fil, concernant le service d'affichage LAN sans fil et des informations sur un deuxième mode de fonctionnement, du deuxième dispositif sans fil, se rapportant au service MA-USB; et permettre au premier dispositif sans fil d'identifier, en fonction du message de réponse de mDNS, les informations sur le premier mode de fonctionnement, du deuxième dispositif sans fil, concernant le service d'affichage LAN sans fil et le deuxième mode de fonctionnement, du deuxième dispositif sans fil, concernant le service MA-USB, le message d'interrogation de mDNS et le message de réponse de mDNS pouvant être transmis par l'intermédiaire d'un point d'accès (AP).
PCT/KR2019/009047 2018-07-25 2019-07-23 Procédé de prise en charge de connexion de bus série universel agnostique par rapport au support (ma-usb), et dispositif sans fil utilisant celui-ci WO2020022728A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2018-0086512 2018-07-25
KR20180086512 2018-07-25

Publications (1)

Publication Number Publication Date
WO2020022728A1 true WO2020022728A1 (fr) 2020-01-30

Family

ID=69180589

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/009047 WO2020022728A1 (fr) 2018-07-25 2019-07-23 Procédé de prise en charge de connexion de bus série universel agnostique par rapport au support (ma-usb), et dispositif sans fil utilisant celui-ci

Country Status (1)

Country Link
WO (1) WO2020022728A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140337544A1 (en) * 2013-05-08 2014-11-13 Qualcomm Incorporated Transport mode for wireless serial bus (wsb) service
US20150350288A1 (en) * 2014-05-28 2015-12-03 Qualcomm Incorporated Media agnostic display for wi-fi display
US20160085703A1 (en) * 2012-12-27 2016-03-24 Intel Corporation Discovery mechanisms for universal serial bus (usb) protocol adaptation layer
KR20160045845A (ko) * 2013-08-21 2016-04-27 삼성전자주식회사 무선 usb 디바이스들에 대해 지속 usb 서비스를 제공하는 방법 및 장치
WO2017018823A1 (fr) * 2015-07-30 2017-02-02 엘지전자 주식회사 Procédé et dispositif permettant de former une session de plate-forme de service d'application dans un système de communication sans fil

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160085703A1 (en) * 2012-12-27 2016-03-24 Intel Corporation Discovery mechanisms for universal serial bus (usb) protocol adaptation layer
US20140337544A1 (en) * 2013-05-08 2014-11-13 Qualcomm Incorporated Transport mode for wireless serial bus (wsb) service
KR20160045845A (ko) * 2013-08-21 2016-04-27 삼성전자주식회사 무선 usb 디바이스들에 대해 지속 usb 서비스를 제공하는 방법 및 장치
US20150350288A1 (en) * 2014-05-28 2015-12-03 Qualcomm Incorporated Media agnostic display for wi-fi display
WO2017018823A1 (fr) * 2015-07-30 2017-02-02 엘지전자 주식회사 Procédé et dispositif permettant de former une session de plate-forme de service d'application dans un système de communication sans fil

Similar Documents

Publication Publication Date Title
WO2012060611A2 (fr) Procédé de recherche de dispositif et dispositif de communication l'utilisant
WO2019164268A1 (fr) Procédé de connexion sans fil dans un système de réseau local sans fil et dispositif sans fil l'utilisant
US9986591B2 (en) Function execution apparatus
WO2020226360A1 (fr) Appareil et procédé destinés à prendre en charge une horloge de référence de temps d'arrivée de rafale sur la base d'informations d'aide à la communication sensibles au temps dans un réseau de communication sans fil
WO2018236145A1 (fr) Appareil et procédé de découverte de services de liaison montante et d'accès à ceux-ci dans un système de communication sans fil
WO2013073838A1 (fr) Procédé et dispositif de recherche de service pris en charge dans un réseau wi-fi direct
WO2015069031A1 (fr) Procédé et appareil de formation d'une liaison de communications utilisant bluetooth
WO2014088378A1 (fr) Procédé et dispositif permettant une initialisation de session dans un système de communication sans fil
WO2016204574A1 (fr) Procédé de communication sans fil et terminal de communication sans fil permettant de recevoir des données en provenance d'une pluralité de terminaux de communication sans fil
WO2015152502A1 (fr) Système et procédé de communication sans fil
WO2015002385A1 (fr) Procédé et dispositif de communication entre dispositifs dans un système de communications sans fil
WO2016111562A1 (fr) Procédé et appareil pour rapport d'état de batterie dans un wfd
WO2016167618A9 (fr) Procédé et dispositif pour effectuer une découverte de service dans un système de communication sans fil
WO2016148406A1 (fr) Procédé et dispositif pour prendre en charge un service par utilisation d'une plateforme de service d'application dans un système de communication sans fil
WO2016137224A1 (fr) Procédé et appareil pour transmettre des données dans un système de communication sans fil
WO2019177231A1 (fr) Procédé de transfert d'informations sur un point d'accès cible dans un système lan sans fil et point d'accès l'utilisant
WO2016148523A1 (fr) Procédé et dispositif pour exécuter une recherche de service dans un système de communication sans fil
WO2017018823A1 (fr) Procédé et dispositif permettant de former une session de plate-forme de service d'application dans un système de communication sans fil
WO2014030894A1 (fr) Procédé pour la configuration d'une liaison à grande vitesse dans un système wlan, et dispositif pour la mise en œuvre dudit procédé
WO2017043718A1 (fr) Procédé et dispositif permettant à un récepteur wfd de modifier l'orientation d'une image
WO2017039376A1 (fr) Procédé et dispositif permettant l'échange d'informations de capacité de connexion dans un système de communication sans fil
WO2018074871A1 (fr) Procédé de communication sans fil utilisant un vecteur d'attribution de réseau et terminal de communication sans fil correspondant
WO2016148550A1 (fr) Procédé et appareil permettant d'établir une session de plateforme de service d'application dans un système de communication sans fil
WO2016064168A2 (fr) Procédé de communication sans fil, et terminal de communication sans fil
WO2016190618A1 (fr) Procédé et dispositif pour réaliser un transfert intercellulaire de session dans un système de communication sans fil

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: 19842257

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: 19842257

Country of ref document: EP

Kind code of ref document: A1