WO2019225829A1

WO2019225829A1 - Method for ma-usb-based p2p communication, and wireless device using same

Info

Publication number: WO2019225829A1
Application number: PCT/KR2019/000522
Authority: WO
Inventors: 박기원; 이병주
Original assignee: 엘지전자 주식회사
Priority date: 2018-05-23
Filing date: 2019-01-14
Publication date: 2019-11-28

Abstract

A method by which a first wireless device performs peer to peer (P2P) communication, according to one embodiment, comprises the steps of: transmitting, to a second wireless device, a first request frame for requesting capability information for a media agnostic universal serial bus (MA-USB) of the second wireless device; receiving a first response frame including the capability information from the second wireless device in response to the first request frame; determining a configuration parameter for a connection according to the MA-USB on the basis of the capability information; and transmitting, to the second wireless device, a second request frame including first operation information for the determined configuration information and second operation information for informing of enabling of the connection according to the MA-USB.

Description

Method for P2P communication based on MA-USB and wireless device using same

The present disclosure relates to wireless communication, and more particularly, to a method for P2P communication based on MA-USB 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 (that is, 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 P2P communication based on MA-USB having an improved performance in terms of a user interface and a wireless device using the same.

Method for peer to peer (P2P) communication performed by the first wireless device according to an embodiment of the present invention, a. Sending a first request frame to a second wireless device; Receiving from the second wireless device a first response frame that includes capability information in response to the first request frame; Determining setting parameters for connection according to MA-USB based on the capability information; And sending a second request frame to the second wireless device, the second request frame comprising first operation information for the determined configuration parameter and second operation information for informing that the connection according to the MA-USB will be enabled.

According to an embodiment of the present disclosure, a method for P2P communication based on MA-USB having improved performance in terms of a user interface and a wireless device using the same may be provided.

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 illustrating 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 is a flowchart illustrating a method for P2P communication based on MA-USB according to the present embodiment.

10 is a flowchart illustrating a method for setting P2P communication based on MA-USB according to the present embodiment.

11 is a flowchart illustrating a method for updating P2P communication based on MA-USB according to the present embodiment.

12 is a flowchart illustrating a method for P2P communication based on MA-USB according to another embodiment.

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

14 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 disclosure, it is necessary to clarify that any of these methods may be implemented in any of the specific or equivalent thereof.

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 terminology used herein has the meaning commonly understood by one 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 architecture may be composed of a plurality of components, and a wireless LAN system supporting transparent STA mobility to upper layers by their interaction may be provided in a wireless local system. 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. A 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 a device 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 for supporting direct connection between devices, a 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 support for direct device-to-device communication while retaining most of the functionality of the existing Wi-Fi standard. Therefore, 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.

In the P2P group, there is a device that plays the role of an AP in an existing infrastructure network. In the P2P specification, the device is called a P2P group owner (hereinafter referred to as 'P2P GO'). 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 the "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 for transferring 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. The WFD devices in the WFD network may search for information about the WFD devices (for example, 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 this 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 for the WFD source and the WFD sink and 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. Thereafter, the WFD source and the WFD sink may 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 (ie, performs a rendering procedure) of generating an image and / or sound based on multimedia content received from the WFD source 200 through a P2P link. 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 to 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, various types of WFD sessions shown in FIG. 3 may be established after performing a procedure to be described with reference to FIG. 4.

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 establish 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.

Referring to the top 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 the 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 a 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 with reference to 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 the RTSP M2 request message is received, in step S604, the WFD source may respond with an RTSP M2 response message that lists 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, a 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 an 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 the successful establishment of an 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 WFD source and WFD sink, RTSP triggering the WFD sink to send 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 the 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 can be sent to the WFD source for enable or disable. .

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

When a 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 commonly supported by both. By using a codec commonly supported by the WFD source and the WFD sink, interoperability between the two can be guaranteed.

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 understood as 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 setting 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 the Wi-Fi serial bus (hereinafter, 'WSB') may be used interchangeably with the same meaning.

9 is a flowchart illustrating a method for P2P communication based on MA-USB according to the present embodiment. The first wireless device 910 of FIG. 9 may be understood as a WFD source, and the second wireless device 920 may be understood as a WFD sink.

Although not shown in FIG. 9, a WFD device discovery procedure (eg, S401 correspondence) may be performed between the first wireless device 910 and the second wireless device 920.

For example, a WFD information element (IE) for a WFD device discovery procedure according to the present embodiment may be defined as shown in Table 1 below.

Referring to Table 1 above, the WFD Extended capabilities bitmap field in which two octets are allocated in the WFD IE may be as shown in Table 2 below.

Referring to Table 2 above, the seventh bit of the WFD Extended capabilities bitmap field may be allocated for information on whether the WFD UE searched through the WFD device discovery procedure supports the WSB.

In addition, in order to distinguish a device type of a WFD terminal searched through a WFD device discovery procedure, a WFD information element (WFD IE) may be defined as shown in Table 3 below.

Referring to Table 3 above, the WFD R3 Device Information field in which 2 octets are allocated in the WFD IE may be as shown in Table 4 below.

Referring to Table 4 above, in order to indicate the device type of the WFD terminal, WSB Device Type bits which are 2-bit information in the WFD R3 Device Information field may be allocated.

For example, when the 2-bit information is '00', the device type of the WFD terminal may be a host type. When the 2-bit information is '01', the device type of the WFD terminal may be a device type. If the 2-bit information is '10', the device type of the WFD terminal may be a hub type.

During the WFD device discovery procedure, a probe request frame and a probe response frame may be exchanged between the first wireless device 910 that is a WFD source and the second wireless device 920 that is a WFD sink.

For example, the second wireless device 920 may receive a probe request frame including a WFD Extended capabilities bitmap field from the first wireless device 910. In this case, the WFD Extended capabilities bitmap field may include information corresponding to 'supported'.

In addition, when the second wireless device 920 supports MA-USB, the second wireless device 920 may set information corresponding to 'supported' in the WFD Extended capabilities bitmap field. Subsequently, the second wireless device 920 may transmit a probe response frame including information corresponding to 'supported' and information corresponding to the device type of the second wireless device 920.

In addition, when the second wireless device 920 does not support the MA-USB, the second wireless device 920 may set information corresponding to 'not supported' in the WFD Extended capabilities bitmap field. Subsequently, the second wireless device 920 may transmit a probe response frame including information corresponding to 'not supported'.

When the WFD device discovery procedure is completed, a Wi-Fi connection procedure may be performed between the first wireless device 910 and the second wireless device 920.

For example, the Wi-Fi connection procedure may correspond to step S403 of FIG. 4. For example, the first wireless device 910 and the second wireless device 920 may be connected based on a Wi-Fi P2P link.

When the Wi-Fi connection procedure is completed, a TCP connection for the RTSP session may be established based on the 3-way handshake between the first wireless device 910 and the second wireless device 920.

When the TCP connection is completed, a procedure for WFD capability negotiation may be performed between the first wireless device 910 and the second wireless device 920.

6 and 9, operation S910 of FIG. 9 may correspond to operation S605 of FIG. 6.

Although not shown in FIG. 9, FIG. 9 shows an RTSP M1 request message, an RTSP M1 response message, an RTSP M2 request message, and an RTSP M2 response message as shown in FIG. 6. It is explained on the premise that they are exchanged in advance.

In operation S910, the first wireless device 910 may transmit an RTSP M3 request message to the second wireless device 920. The RTSP M3 request message of FIG. 9 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 920 that is a WFD sink.

In addition, to request capability information for the MA-USB Media Agnostic Universal Serial Bus (MAS) of the second wireless device 920, the RTSP M3 request message according to the present embodiment may include mausb-capability information as shown in Table 5 below. Can be.

In operation S920, the first wireless device 910 may receive an RTSP M3 response message from the second wireless device 920 in response to the RTSP M3 request message. The RTSP M3 response message of FIG. 9 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 920 that is the WFD sink to the first wireless device 910.

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

For example, the RTSP M3 response message may include information about the device type of the second wireless device 920 and information about the transportMode of the second wireless device 920.

Subsequently, the first wireless device 910 based on the capability information for its MA-USB and the capability information for the MA-USB of the second wireless device 920, the first wireless device 910 and the second wireless device. The configuration parameter for the connection according to the MA-USB between 920 may be determined.

In operation S930, the first wireless device 910 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 920. The RTSP M4 request message of FIG. 9 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 status of the connection according to the MA-USB of the second wireless device 920 as 'disable' or 'enable'. For clear and concise understanding of FIG. 9, it can be assumed that mausb-setting information is set to 'enable'.

In operation S940, the first wireless device 910 may receive an RTSP M4 response message from the second wireless device 920 in response to the RTSP M4 request message. The RTSP M4 response message of FIG. 9 may include an 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 920.

When steps S910 to S940 of FIG. 9 are performed, a procedure for negotiating capabilities for connection according to MA-USB between the first wireless device 910 and the second wireless device 920 may be completed.

Although not shown in FIG. 9, after the steps S910 to S940 of FIG. 9 are performed, the procedure of FIG. 7 may be performed to establish a WFD session between the first wireless device 910 and the second wireless device 920. . That is, when a WFD session between the first wireless device 910 and the second wireless device 920 is established, an AV stream may be transmitted.

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

That is, according to the present embodiment, not only screen mirroring but also media files may be exchanged in both directions. Accordingly, a method for P2P communication based on MA-USB having an improved performance in terms of a user interface and a wireless device using the same can be provided.

10 is a flowchart illustrating a method for setting P2P communication based on MA-USB according to the present embodiment. For a clear and concise understanding of FIG. 10, it can be assumed that the steps mentioned in FIG. 9 are performed prior to the operation of FIG. 10.

Referring to FIG. 10, the first wireless device 1010 of FIG. 10 may correspond to the first wireless device 910 of FIG. 9. In addition, the second wireless device 1020 of FIG. 10 may correspond to the second wireless device 920 of FIG. 9.

In operation S1010, the first wireless device 1010 may transmit an M28 request message for requesting connection according to the MA-USB to the second wireless device 1020. The M28 request message may include an RTSP SET_PARAMETER Request.

For example, the M28 request message may include mausb-capability information as shown in Table 5 above.

In operation S1020, the second wireless device 1020 may transmit an M28 response message to the first wireless device 1010 in response to the M28 request message. The M28 response message may include RTSP SET_PARAMETER Response.

For example, the M28 response message may include the result information of 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.

For example, an M28 request message for requesting a connection according to MA-USB may be transmitted regardless of the device type (ie, host type, device type or hub type).

In operation S1030, a TCP connection may be established between the first wireless device 1010 and the second wireless device 1020 for data exchange based on the MA-USB.

For example, it will be appreciated that step S1030 is performed when the IP transport for the first wireless device 1010 and the second wireless device 1020 is TCP.

For example, a wireless device with the role of a MA-USB device 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 may be performed based on the negotiated TCP port based on the wfd3-mausb capbility information of Table 5.

As shown in FIG. 10, when a connection based on MA-USB and a TCP connection are established, data exchange based on MA-USB may be enabled between the first wireless device 1010 and the second wireless device 1020. .

Although the example of FIG. 10 is described between a MA-USB device and a MA-USB host, it will 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.

For a clear and concise understanding of FIG. 11, it can be assumed that the steps mentioned in FIGS. 9 and 10 are performed prior to the operation of FIG. 11.

Referring to FIG. 11, in order to update the status of a connection according to a pre-established MA-USB, an M29 request message and an M29 response message may be used.

In order to tear down the connection according to the pre-established MA-USB between the first wireless device 1110 and the second wireless device 1120, steps S1110 and S1120 may be performed.

In operation S1110, the first wireless device 1110 may transmit an M29 request message to the second wireless device 1120 to release the connection according to the MA-USB. In this case, the M29 request message may include an RTSP SET_PARAMETER Request. For example, the M29 request message may include mausb-setting information set to 'disable'.

In operation S1120, the second wireless device 1120 may transmit an M29 response message, which is a response to the M29 request message, to the second wireless device 1120. In this case, the M29 response message may include RTSP SET_PARAMETER Response. For example, the M29 response message may include information for accepting the release of the connection according to the MA-USB.

That is, when steps S1110 and S1120 are performed, the connection according to the MA-USB established in advance between the first wireless device 1110 and the second wireless device 1120 may be released.

In addition, steps S1130 and S1140 may be performed to re-establish the connection according to the released MA-USB between the first wireless device and the second wireless device.

In operation S1130, the first wireless device 1110 may transmit an M29 request message to the second wireless device 1120 in order to reestablish a connection according to the MA-USB. In this case, the M29 request message may include an RTSP SET_PARAMETER Request. For example, the M29 request message may include mausb-setting information set to 'enable'.

In operation S1140, the second wireless device 1120 may transmit an M29 response message, which is a response to the M29 request message, to the second wireless device 1120. In this case, the M29 response message may include RTSP SET_PARAMETER Response. For example, the M29 response message may include information for accepting reestablishment of the connection according to the MA-USB.

For example, an M29 request message for updating a connection according to MA-USB may be transmitted regardless of the device type (ie, host type, device type or hub type).

9 and 12, the step S1210 of FIG. 12 may correspond to the step of FIG. 9. In addition, step S1220 of FIG. 12 may correspond to step S920 of FIG. 9.

In another embodiment of FIG. 12, in order to directly set a MA-USB data path, an operation S1230 for TCP connection may be directly performed without exchanging an RTSP M5 to RTSP M7 message shown in FIG. 7. have.

According to the embodiment of FIG. 12, although the screen of the first wireless device 910 is not screen mirrored to the second wireless device 920, the first wireless device 910 and the second wireless device 920 are based on the MTP connection. Media files may be exchanged between That is, media files can be exchanged in both directions without screen mirroring.

Referring to FIG. 13, 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. 13 includes a processor 1310, a memory 1320, and a transceiver 1330 as shown. The illustrated processor 1310, the memory 1320, and the transceiver 1330 may be implemented as separate chips, or at least two blocks / functions may be implemented through one chip.

The transceiver 1330 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 1330 may include one or more antennas for transmitting and / or receiving wireless signals. In addition, the transceiver 1330 may include an amplifier for amplifying the reception signal and / or the transmission signal and a bandpass filter for transmission on a specific frequency band.

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

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

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

For convenience of description, an example of FIG. 14 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 processor 1410 generates transmission data (control data and / or user data) corresponding to the transmission signal. The output of the data processor 1410 may be input to the encoder 1420. The encoder 1420 may perform coding through a binary convolutional code (BCC) or a low-density parity-check (LDPC) technique. At least one encoder 1420 may be included, and the number of encoders 1420 may be determined according to various information (for example, the number of data streams).

The output of the encoder 1420 may be input to the interleaver 1430. The interleaver 1430 distributes a continuous bit signal over radio resources (eg, time and / or frequency) to prevent burst errors due to fading or the like. At least one interleaver 1430 may be included, and the number of the interleaver 1430 may be determined according to various information (for example, the number of spatial streams).

The output of the interleaver 1430 may be input to a constellation mapper 1440. The constellation mapper 1440 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 1440 may be input to the spatial stream encoder 1450. The spatial stream encoder 1450 performs data processing to transmit the transmission signal through at least one spatial stream. For example, the spatial stream encoder 1450 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 1450 may be input to an IDFT 1460 block. The IDFT 1460 block performs an inverse discrete Fourier transform (IDFT) or an inverse Fast Fourier transform (IFFT).

The output of the IDFT 1460 block is input to the Guard Interval (GI) inserter 1470, and the output of the GI inserter 1470 is input to the transceiver 1330 of FIG. 13.

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 determined not only by the claims below but also by the equivalents of the claims of the present invention.

Claims

In the method for peer to peer (P2P) communication,

Sending, by the first wireless device, a first request frame to the second wireless device requesting capability information for a Media Agnostic Universal Serial Bus (MA-USB) of the second wireless device;

Receiving, by the first wireless device, a first response frame containing the capability information from the second wireless device in response to the first request frame;

Determining, by the first wireless device, a configuration parameter for connection according to the MA-USB based on the capability information; And

The second request frame includes a second request frame including first operation information for the determined configuration parameter and second operation information for notifying that the connection according to the MA-USB will be enabled. Transmitting to the wireless device.
According to claim 1,

First acknowledgment information indicating that the first operation information is accepted by the second wireless device in response to the second request frame, and the second operation information by the second wireless device; Receiving a second response frame from the second wireless device, the second response frame including second acknowledgment information indicating acknowledgment.
The method of claim 2,

Sending, by the first wireless device, to the second wireless device a third request frame requesting the connection according to the MA-USB; And

The first wireless device receives a third response frame from the second wireless device in response to the third request frame, wherein the third response frame is configured to connect the second wireless device to the MA-USB. Comprising information informing that it is accepted by.
The method of claim 2,

Receiving, by the first wireless device, from the second wireless device a third request frame requesting the connection according to the MA-USB; And

The first wireless device transmits a third response frame to the second wireless device in response to the third request frame, wherein the third response frame is configured to connect the first wireless device according to the MA-USB. Comprising information informing that it is accepted by.
According to claim 1,

And the first wireless device is connected with the second wireless device based on a WiFi P2P link.
In a first wireless device performing a method for peer to peer (P2P) communication, the first wireless device,

A transceiver for transmitting and receiving a radio signal; And

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

Is configured to transmit a first request frame to the second wireless device requesting capability information for a Media Agnostic Universal Serial Bus (MA-USB) of a second wireless device,

Is configured to receive a first response frame from the second wireless device that includes the capability information in response to the first request frame,

Wherein the first wireless device is configured to determine a setup parameter for connection according to the MA-USB based on the capability information,

The second request frame includes a second request frame including first operation information for the determined configuration parameter and second operation information for notifying that the connection according to the MA-USB will be enabled. A wireless device implemented to transmit to a wireless device.
The method of claim 6,

The processor,

First approval information indicating that the first operation information is accepted by the second wireless device in response to the second request frame and second approval information indicating that the second operation information is accepted by the second wireless device. The wireless device is further implemented to receive a second response frame from the second wireless device.
The method of claim 7, wherein

The processor,

Transmit a third request frame for requesting the connection according to the MA-USB to the second wireless device,

Further configured to receive a third response frame from the second wireless device in response to the third request frame, wherein the third response frame indicates that the connection according to the MA-USB is accepted by the second wireless device. Wireless device that includes the information to inform.
The method of claim 7, wherein

The processor,

And receive a third request frame from the second wireless device requesting the connection according to the MA-USB,

And further send a third response frame to the second wireless device in response to the third request frame, wherein the third response frame indicates that the connection according to the MA-USB is accepted by the first wireless device. Wireless device that includes the information to inform.
The method of claim 6,

The first wireless device is connected with the second wireless device based on a WiFi P2P link.