WO2019225829A1 - Procédé pour une communication p2p basée sur un ma-usb, et dispositif sans fil utilisant le procédé - Google Patents

Procédé pour une communication p2p basée sur un ma-usb, et dispositif sans fil utilisant le procédé Download PDF

Info

Publication number
WO2019225829A1
WO2019225829A1 PCT/KR2019/000522 KR2019000522W WO2019225829A1 WO 2019225829 A1 WO2019225829 A1 WO 2019225829A1 KR 2019000522 W KR2019000522 W KR 2019000522W WO 2019225829 A1 WO2019225829 A1 WO 2019225829A1
Authority
WO
WIPO (PCT)
Prior art keywords
wireless device
wfd
usb
response
rtsp
Prior art date
Application number
PCT/KR2019/000522
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 WO2019225829A1 publication Critical patent/WO2019225829A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • 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.
  • 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.
  • P2P peer to peer 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.
  • 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.
  • 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 illustrating 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. 9 is a flowchart illustrating a method for P2P communication based on MA-USB according to the present embodiment.
  • FIG. 10 is a flowchart illustrating a method for setting P2P communication based on MA-USB according to the present embodiment.
  • FIG. 11 is a flowchart illustrating a method for updating P2P communication based on MA-USB according to the present embodiment.
  • FIG. 12 is a flowchart illustrating a method for P2P communication based on MA-USB according to another embodiment.
  • FIG. 13 is a block diagram illustrating a wireless device to which the present embodiment can be applied.
  • FIG. 14 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 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").
  • WLAN wireless local system. area network
  • 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.
  • 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.
  • 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 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.
  • Wi-Fi Direct 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.
  • WFD Wi-Fi Direct
  • WFD Wi-Fi Direct
  • Wi-Fi Direct 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.
  • P2P group there is a device that plays the role of an AP in an existing infrastructure network.
  • the device In the P2P specification, the device is called a P2P group owner (hereinafter referred to as 'P2P GO').
  • P2P group owner hereinafter referred to as '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').
  • 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 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.
  • 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.
  • 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'
  • 'IP' internet protocol
  • TCP transmission control protocol
  • RTSP real time streaming protocol
  • RTP real time protocol
  • a capability negotiation procedure between the WFD source and the WFD sink may be performed via RTSP.
  • the WFD source and the WFD sink may exchange RTSP based messages (ie, M1 through M4) during the capability negotiation procedure. Thereafter, the WFD source and the WFD sink may exchange WFD session control messages.
  • 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.
  • 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 (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.
  • 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 to 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.
  • various types of WFD sessions shown in FIG. 3 may be established after performing a procedure to be described with reference to FIG. 4.
  • 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
  • a specific connection scheme eg Wi-Fi P2P or Tunneled Direct Link Setup, hereinafter 'TDLS'
  • Wi-Fi P2P or Tunneled Direct Link Setup hereinafter 'TDLS'
  • 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.
  • 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 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.
  • 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 a TDLS link
  • 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 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.
  • 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 that lists 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 an 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 the successful establishment of an 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 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).
  • 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 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.
  • the WFD source and the WFD sink can proceed with audio / video streaming using a codec commonly supported by both.
  • a codec commonly supported by the WFD source and the WFD sink By using 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 understood as 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 setting 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 the Wi-Fi serial bus (hereinafter, 'WSB') may be used interchangeably with the same meaning.
  • 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.
  • a WFD device discovery procedure (eg, S401 correspondence) may be performed between the first wireless device 910 and the second wireless device 920.
  • IE WFD information element
  • the WFD Extended capabilities bitmap field in which two octets are allocated in the WFD IE may be as shown in Table 2 below.
  • 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.
  • a WFD information element (WFD IE) may be defined as shown in Table 3 below.
  • the WFD R3 Device Information field in which 2 octets are allocated in the WFD IE may be as shown in Table 4 below.
  • WSB Device Type bits which are 2-bit information in the WFD R3 Device Information field may be allocated.
  • the device type of the WFD terminal may be a host type.
  • the device type of the WFD terminal may be a device type.
  • the device type of the WFD terminal may be a hub type.
  • 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.
  • the second wireless device 920 may receive a probe request frame including a WFD Extended capabilities bitmap field from the first wireless device 910.
  • the WFD Extended capabilities bitmap field may include information corresponding to 'supported'.
  • 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.
  • 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'.
  • a Wi-Fi connection procedure may be performed between the first wireless device 910 and the second wireless device 920.
  • the Wi-Fi connection procedure may correspond to step S403 of FIG. 4.
  • the first wireless device 910 and the second wireless device 920 may be connected based on a Wi-Fi P2P link.
  • 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.
  • a procedure for WFD capability negotiation may be performed between the first wireless device 910 and the second wireless device 920.
  • operation S910 of FIG. 9 may correspond to operation S605 of FIG. 6.
  • 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.
  • 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.
  • the RTSP M3 request message may include mausb-capability information as shown in Table 5 below. Can be.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 status of the connection according to the MA-USB of the second wireless device 920 as 'disable' or 'enable'.
  • mausb-setting information is set to 'enable'.
  • 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.
  • 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.
  • steps S910 to S940 of FIG. 9 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.
  • 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.
  • the screen of the first wireless device 910 may be screen mirrored to the second wireless device 920.
  • a media file may be exchanged between the first wireless device 910 and the second wireless device 920 based on the MTP connection.
  • FIG. 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.
  • the first wireless device 1010 of FIG. 10 may correspond to the first wireless device 910 of FIG. 9.
  • the second wireless device 1020 of FIG. 10 may correspond to the second wireless device 920 of FIG. 9.
  • 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.
  • the M28 request message may include mausb-capability information as shown in Table 5 above.
  • 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.
  • the M28 response message may include the result information of 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 the device type (ie, host type, device type or hub type).
  • 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.
  • step S1030 is performed when the IP transport for the first wireless device 1010 and the second wireless device 1020 is TCP.
  • 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.
  • 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 may be performed based on the negotiated TCP port based on the wfd3-mausb capbility information of Table 5.
  • data exchange based on MA-USB may be enabled between the first wireless device 1010 and the second wireless device 1020.
  • 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.
  • FIG. 11 is a flowchart illustrating a method for updating P2P communication based on MA-USB according to the present embodiment.
  • an M29 request message and an M29 response message may be used.
  • steps S1110 and S1120 may be performed.
  • 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.
  • the M29 request message may include an RTSP SET_PARAMETER Request.
  • the M29 request message may include mausb-setting information set to 'disable'.
  • 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.
  • the M29 response message may include RTSP SET_PARAMETER Response.
  • the M29 response message may include information for accepting the release of the connection according to the MA-USB.
  • 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.
  • 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.
  • 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.
  • the M29 request message may include an RTSP SET_PARAMETER Request.
  • the M29 request message may include mausb-setting information set to 'enable'.
  • 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.
  • the M29 response message may include RTSP SET_PARAMETER Response.
  • the M29 response message may include information for accepting reestablishment of the connection according to the MA-USB.
  • 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).
  • FIG. 12 is a flowchart illustrating a method for P2P communication based on MA-USB according to another embodiment.
  • step S1210 of FIG. 12 may correspond to the step of FIG. 9.
  • step S1220 of FIG. 12 may correspond to step S920 of FIG. 9.
  • an operation S1230 for TCP connection may be directly performed without exchanging an RTSP M5 to RTSP M7 message shown in FIG. 7. have.
  • 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.
  • FIG. 13 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. 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.
  • 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.
  • 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.
  • ASIC application-specific integrated circuit
  • the memory 1320 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.
  • FIG. 14 is a block diagram illustrating an example of an apparatus included in a processor.
  • FIG. 14 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).
  • BCC binary convolutional code
  • LDPC low-density parity-check
  • 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.
  • Radio resources eg, time and / or frequency
  • 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.
  • 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.
  • STBC space-time block coding
  • CSS cyclic shift diversity
  • 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).
  • IDFT inverse discrete Fourier transform
  • IFFT inverse Fast Fourier transform
  • 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.
  • GI Guard Interval

Landscapes

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

Abstract

Un mode de réalisation de l'invention concerne un procédé par lequel un premier dispositif sans fil exécute une communication de poste à poste (P2P). Le procédé comprend les étapes consistant à : transmettre, à un second dispositif sans fil, une première trame de demande utilisée pour demander des informations de capacité relatives à un bus série universel indépendant du support (MA-USB) du second dispositif sans fil ; recevoir une première trame de réponse contenant les informations de capacité, du second dispositif sans fil, en réponse à la première trame de demande ; déterminer un paramètre de configuration pour une connexion selon le MA-USB, sur la base des informations de capacité ; et transmettre, au second dispositif sans fil, une seconde trame de demande contenant des premières informations d'opération pour les informations de configuration déterminées, et des secondes informations opérationnelles pour informer de l'activation de la connexion selon le MA-USB.
PCT/KR2019/000522 2018-05-23 2019-01-14 Procédé pour une communication p2p basée sur un ma-usb, et dispositif sans fil utilisant le procédé WO2019225829A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20180058436 2018-05-23
KR20180058437 2018-05-23
KR10-2018-0058437 2018-05-23
KR10-2018-0058436 2018-05-23
KR10-2018-0066687 2018-06-11
KR20180066687 2018-06-11

Publications (1)

Publication Number Publication Date
WO2019225829A1 true WO2019225829A1 (fr) 2019-11-28

Family

ID=68616380

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/000522 WO2019225829A1 (fr) 2018-05-23 2019-01-14 Procédé pour une communication p2p basée sur un ma-usb, et dispositif sans fil utilisant le procédé

Country Status (1)

Country Link
WO (1) WO2019225829A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021179970A1 (fr) * 2020-03-12 2021-09-16 华为技术有限公司 Procédé et appareil de transmission de données

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014185955A1 (fr) * 2013-05-16 2014-11-20 Intel Corporation Systèmes et procédés de découverte et d'utilisation de protocoles de communication sans fil pour l'accès à des services par des dispositifs wi-fi
KR20160005754A (ko) * 2013-05-08 2016-01-15 퀄컴 인코포레이티드 무선 직렬 버스(wsb) 서비스에 대한 트랜스포트 모드
KR20170013873A (ko) * 2014-05-28 2017-02-07 퀄컴 인코포레이티드 Wi-fi 디스플레이를 위한 미디어 애그노스틱 디스플레이
KR20170090664A (ko) * 2016-01-29 2017-08-08 삼성전자주식회사 테더링 서비스를 제공하는 방법 및 이를 사용하는 전자 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160005754A (ko) * 2013-05-08 2016-01-15 퀄컴 인코포레이티드 무선 직렬 버스(wsb) 서비스에 대한 트랜스포트 모드
WO2014185955A1 (fr) * 2013-05-16 2014-11-20 Intel Corporation Systèmes et procédés de découverte et d'utilisation de protocoles de communication sans fil pour l'accès à des services par des dispositifs wi-fi
KR20170013873A (ko) * 2014-05-28 2017-02-07 퀄컴 인코포레이티드 Wi-fi 디스플레이를 위한 미디어 애그노스틱 디스플레이
KR20170090664A (ko) * 2016-01-29 2017-08-08 삼성전자주식회사 테더링 서비스를 제공하는 방법 및 이를 사용하는 전자 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HEWLETT-PACKARD, INTEL , LSI , MICROSOFT , NEC , SAMSUNG , ST-ERICSSON: "Wireless Universal Serial Bus Specification 1.1", 9 September 2010 (2010-09-09), pages 1 - 325, XP055655825, Retrieved from the Internet <URL:http://www.softelectro.ru/usbwr11.pdf> *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021179970A1 (fr) * 2020-03-12 2021-09-16 华为技术有限公司 Procédé et appareil de transmission de données
CN113473645A (zh) * 2020-03-12 2021-10-01 华为技术有限公司 数据传输方法和装置

Similar Documents

Publication Publication Date Title
WO2012060611A2 (fr) Procédé de recherche de dispositif et dispositif de communication l&#39;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&#39;arrivée de rafale sur la base d&#39;informations d&#39;aide à la communication sensibles au temps dans un réseau de communication sans fil
WO2014088378A1 (fr) Procédé et dispositif permettant une initialisation de session dans un système de communication sans fil
WO2016024770A1 (fr) Procédé et dispositif pour permettre à une station de recevoir un signal dans un système de communication sans fil
WO2019164268A1 (fr) Procédé de connexion sans fil dans un système de réseau local sans fil et dispositif sans fil l&#39;utilisant
WO2013073838A1 (fr) Procédé et dispositif de recherche de service pris en charge dans un réseau wi-fi direct
WO2019177231A1 (fr) Procédé de transfert d&#39;informations sur un point d&#39;accès cible dans un système lan sans fil et point d&#39;accès l&#39;utilisant
WO2016111562A1 (fr) Procédé et appareil pour rapport d&#39;état de batterie dans un wfd
WO2016148406A1 (fr) Procédé et dispositif pour prendre en charge un service par utilisation d&#39;une plateforme de service d&#39;application dans un système de communication sans fil
WO2016167618A9 (fr) Procédé et dispositif pour effectuer une découverte de service dans un système de communication sans fil
WO2016186403A1 (fr) Procédé de communication sans fil et terminal de communication sans fil pour une réception de données en provenance d&#39;une pluralité de terminaux de communication sans fil sur la base d&#39;un accès aléatoire
WO2016137224A1 (fr) Procédé et appareil pour transmettre des données dans un système de communication sans fil
WO2014030894A1 (fr) Procédé pour la configuration d&#39;une liaison à grande vitesse dans un système wlan, et dispositif pour la mise en œuvre dudit procédé
WO2017018823A1 (fr) Procédé et dispositif permettant de former une session de plate-forme de service d&#39;application dans un système de communication sans fil
WO2017014579A1 (fr) Procédé et appareil de réalisation de découverte dans un système de communication sans fil
WO2017043718A1 (fr) Procédé et dispositif permettant à un récepteur wfd de modifier l&#39;orientation d&#39;une image
WO2013122395A1 (fr) Procédé et appareil pour l&#39;établissement d&#39;une liaison à haut débit dans un système wlan
WO2018074871A1 (fr) Procédé de communication sans fil utilisant un vecteur d&#39;attribution de réseau et terminal de communication sans fil correspondant
WO2016209019A1 (fr) Procédé et appareil d&#39;exécution d&#39;une recherche à l&#39;aide d&#39;un mdns dans un système de communication sans fil
WO2016148550A1 (fr) Procédé et appareil permettant d&#39;établir une session de plateforme de service d&#39;application dans un système 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
WO2017155271A1 (fr) Procédé et appareil pour recevoir une diffusion en continu par l&#39;intermédiaire d&#39;un protocole de transport dans un système de communication sans fil
WO2019194391A1 (fr) Procédé de transfert d&#39;informations relatives à un dispositif sans fil dans un système lan sans fil, et terminal configurateur l&#39;utilisant
WO2019225829A1 (fr) Procédé pour une communication p2p basée sur un ma-usb, et dispositif sans fil utilisant le procédé

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

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

Country of ref document: EP

Kind code of ref document: A1