WO2016126138A1 - Procédé et dispositif pour établir une session dans un système de communication sans fil - Google Patents

Procédé et dispositif pour établir une session dans un système de communication sans fil Download PDF

Info

Publication number
WO2016126138A1
WO2016126138A1 PCT/KR2016/001307 KR2016001307W WO2016126138A1 WO 2016126138 A1 WO2016126138 A1 WO 2016126138A1 KR 2016001307 W KR2016001307 W KR 2016001307W WO 2016126138 A1 WO2016126138 A1 WO 2016126138A1
Authority
WO
WIPO (PCT)
Prior art keywords
wfd
transmission mode
frame
field
service
Prior art date
Application number
PCT/KR2016/001307
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 WO2016126138A1 publication Critical patent/WO2016126138A1/fr

Links

Images

Classifications

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

Definitions

  • the following description relates to a wireless communication system, and more particularly, to a method and apparatus for establishing an application service platform (ASP) session.
  • ASP application service platform
  • WLAN is based on radio frequency technology, and can be used in homes, businesses, or businesses by using portable terminals such as personal digital assistants (PDAs), laptop computers, and portable multimedia players (PMPs). It is a technology that allows wireless access to the Internet in a specific service area.
  • PDAs personal digital assistants
  • PMPs portable multimedia players
  • Wi-Fi Direct Wi-Fi Direct
  • Wi-Fi P2P peer
  • Wi-Fi Direct devices can be connected without a complicated configuration process, and in order to provide various services to a user, they can support an operation of exchanging data with each other at a communication speed of a general WLAN system.
  • Wi-Fi Direct Service WFDS
  • ASP application service platform
  • IEEE 802.11a and b use an unlicensed band at 2.4. GHz or 5 GHz, IEEE 802.11b provides a transmission rate of 11 Mbps, and IEEE 802.11a provides a transmission rate of 54 Mbps.
  • IEEE 802.11g applies Orthogonal Frequency Division Multiplexing (OFDM) at 2.4 GHz to provide a transmission rate of 54 Mbps.
  • IEEE 802.11n provides a transmission rate of 300 Mbps by applying multiple input multiple output OFDM (MIMO-OFDM). IEEE 802.11n supports a channel bandwidth of up to 40 MHz, in which case it provides a transmission rate of 600 Mbps.
  • OFDM Orthogonal Frequency Division Multiplexing
  • the DLS (Direct Link Setup) related protocol in a wireless LAN environment according to IEEE 802.11e is based on QBSS (Quality BSS) in which a Basic Service Set (BSS) supports Quality of Service (QoS).
  • QBSS Quality BSS
  • AP non-AP
  • QAPs QAPs
  • WLAN environment for example, WLAN environment according to IEEE 802.11a / b / g
  • the AP supports QoS even if the Non-AP STA is a QSTA (Quality STA) supporting QoS.
  • Most legacy APs do not.
  • the QSTA there is a limit that can not use the DLS service.
  • Tunneled Direct Link Setup is a newly proposed wireless communication protocol to overcome this limitation.
  • TDLS does not support QoS
  • QSTAs can set up a direct link even in a wireless LAN environment such as IEEE 802.11a / b / g, which is currently commercialized, and a direct link can be set in a power save mode (PSM). To do that. Therefore, TDLS prescribes various procedures for enabling QSTAs to establish a direct link even in a BSS managed by a legacy AP.
  • a wireless network supporting such a TDLS is called a TDLS wireless network.
  • WLANs mainly dealt with the operation of an infrastructure BSS in which a wireless access point (AP) functions as a hub.
  • the AP is responsible for supporting physical layer support for wireless / wired connection, routing for devices on the network, and providing services for adding / removing devices to and from the network.
  • the devices in the network are connected through the AP, not directly with each other.
  • Wi-Fi Direct The enactment of the Wi-Fi Direct standard has been discussed as a technology to support direct connections between devices.
  • Wi-Fi Direct networks allow Device to Device (D2D) (or Peer-to-Peer) communication with each other, even if Wi-Fi devices do not join home, office, and hotspot networks. It is proposed by the Wi-Fi Alliance as a workable network.
  • Wi-Fi Direct based communication is referred to as Wi-Fi D2D communication (simply, D2D communication) or Wi-Fi P2P communication (simply, P2P communication).
  • Wi-Fi P2P performing device is referred to as a Wi-Fi P2P device, simply P2P device.
  • the WFDS network may include at least one Wi-Fi device.
  • WFDS devices include devices supporting Wi-Fi, such as display devices, printers, digital cameras, projectors, and smartphones.
  • the WFDS device includes a Non-AP STA and an AP STA.
  • WFDS devices in the WFDS network may be directly connected to each other.
  • a signal transmission path between two WFDS devices is directly connected between the corresponding WFDS devices without passing through a third device (for example, an AP) or an existing network (for example, connecting to a WLAN through an AP). It may mean a case where it is set.
  • the signal transmission path directly established between the two WFDS devices may be limited to the data transmission path.
  • P2P communication may refer to a case where a plurality of non-STAs transmit data (eg, voice / video / text information) without passing through the AP.
  • Signal transmission paths for control information e.g., resource allocation information for P2P configuration, wireless device identification information, etc.
  • WFDS devices e.g., Non-AP STA-to-Non-AP STA, Non-AP STA-).
  • Direct-to-AP or between two WFDS devices (e.g., Non-AP STA-to-Non-AP STA) via an AP, or an AP and a corresponding WFDS device (e.g., AP- To-Non-AP STA # 1, AP-to-Non-AP STA # 2).
  • WFDS devices e.g., Non-AP STA-to-Non-AP STA
  • AP- To-Non-AP STA # 1 e.g., AP- To-Non-AP STA # 1
  • Wi-Fi Direct is a network connectivity standard that defines the behavior of the link layer. Since no standard is defined for an application that operates on the upper layer of the link configured by Wi-Fi Direct, it was difficult to support compatibility when devices that support Wi-Fi Direct run applications after they are connected to each other. To address this problem, standardization of the behavior of higher layer applications called Wi-Fi Direct Service (WFDS) is under discussion at the Wi-Fi Alliance (WFA).
  • WFDS Wi-Fi Direct Service
  • FIG. 1 is a diagram for describing a Wi-Fi Direct Service (WFDS) framework component.
  • WFDS Wi-Fi Direct Service
  • the Wi-Fi Direct layer of FIG. 1 means a MAC layer defined by the Wi-Fi Direct standard.
  • the Wi-Fi Direct layer can be configured as software that is compatible with the Wi-Fi Direct standard.
  • a wireless connection may be configured by a physical layer (not shown) compatible with the Wi-Fi PHY.
  • a platform called Application Service Platform (ASP) is defined above the Wi-Fi Direct layer.
  • ASP is a common shared platform and performs session management, command processing of services, and inter-ASP control and security functions between the upper application layer and the lower Wi-Fi Direct layer. do.
  • the service layer contains use case specific services.
  • WFA defines four basic services: Send, Play, Display, and Print.
  • the Enable (API) Application Program Interface (API) is defined to enable the ASP common platform to support third party applications in addition to basic services.
  • FIG. 1 illustrates an example of a service
  • a service defined by Send, Play, Display, Print, or a third party application is not limited thereto.
  • the term "service” refers to Wi-Fi Serial Bus (WSB), Wi-Fi docking (Wi-Fi), in addition to the services defined by the Send, Play, Display, Print, or third-party applications.
  • WB Wi-Fi Serial Bus
  • Wi-Fi docking Wi-Fi docking
  • NAN Neighbor Awareness Networking
  • Send refers to services and applications that can perform file transfers between two WFDS devices.
  • Play refers to services and applications that share or stream audio / video (A / V), photos, and music based on the Digital Living Network Alliance (DLNA) between two WFDS devices.
  • Print refers to services and applications that enable document and photo output between a printer and a device having content such as documents and photos.
  • Display refers to services and applications that enable screen sharing between WFA's Miracast sources and sinks.
  • the application layer may provide a user interface (UI), and expresses information in a form that can be recognized by a person and delivers user input to a lower layer.
  • UI user interface
  • the present invention is to provide a transmission mode according to the capability.
  • a service discovery request to a second device through an AP Transmitting; Receiving, from the AP, a service discovery response sent by the second device; Transmitting a frame related to a transmission mode negotiation to the second device; If the transmission mode negotiation is successful through the frame related to the transmission mode negotiation, the session establishment method comprising the step of transmitting a session request frame using the successful transmission mode.
  • WFDS WiFi Direct Servicea
  • ASP application service platform
  • An embodiment of the present invention provides a first device that supports a WiFi Direct Service (WFDS) and establishes an application service platform (ASP) session with a second device, comprising: a transceiver; And a processor, wherein the processor transmits a service discovery request to a second device through an AP, receives a service discovery response sent by the second device from the AP, and transmits to the second device.
  • the first device transmits a frame related to negotiation and transmits a session request frame using a transmission mode in which negotiation is successful when transmission mode negotiation is successful through the frame related to the transmission mode negotiation.
  • the transmission mode may be one of a user datagram protocol (UDP), a transmission control protocol (TCP), and a media access control (MAC).
  • UDP user datagram protocol
  • TCP transmission control protocol
  • MAC media access control
  • the frame related to the transmission mode negotiation may be a data frame including a MAC header, a frame body, and a 32-bit CRC field.
  • the frame body may include a payload type field indicating an ASP.
  • the frame body may include a Logical Link Control (LLC) field, a Sub-Network Access Protocol (SNAP) field, a payload type field, and a payload field.
  • LLC Logical Link Control
  • SNAP Sub-Network Access Protocol
  • the payload field may include a transport mode bitmap field indicating one of the UDP, TCP, and MAC.
  • the frame related to the transmission mode negotiation may be transmitted through the AP.
  • a customized transmission mode can be used for each STA through the ASP platform.
  • FIG. 1 is a diagram illustrating an exemplary structure of a WFDS system.
  • 3 is a diagram for explaining procedures required for establishing a WFD session.
  • FIG. 7 is a diagram for explaining WFD capability exchange and negotiation.
  • FIG. 8 is a diagram for explaining establishment of a WFD session.
  • 9 to 12 are diagrams for explaining a session establishment procedure according to an embodiment of the present invention.
  • 13 to 14 are block diagrams illustrating a configuration of a wireless device according to an embodiment of the present invention.
  • each component or feature may be considered to be optional unless otherwise stated.
  • Each component or feature may be embodied in a form that is not combined with other components or features.
  • some components and / or features may be combined to form an embodiment of the present invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment.
  • Embodiments of the present invention may be supported by standard documents disclosed in at least one of wireless access systems IEEE 802 system, Wi-Fi system, 3GPP system, 3GPP LTE and LTE-Advanced (LTE-A) system and 3GPP2 system have. That is, steps or parts which are not described to clearly reveal the technical spirit of the present invention among the embodiments of the present invention may be supported by the above documents. In addition, all terms disclosed in the present document can be described by the above standard document.
  • CDMA code division multiple access
  • FDMA frequency division multiple access
  • TDMA time division multiple access
  • OFDMA orthogonal frequency division multiple access
  • SC-FDMA single carrier frequency division multiple access
  • CDMA may be implemented with a radio technology such as Universal Terrestrial Radio Access (UTRA) or CDMA2000.
  • TDMA may be implemented with wireless technologies such as Global System for Mobile communications (GSM) / General Packet Radio Service (GPRS) / Enhanced Data Rates for GSM Evolution (EDGE).
  • GSM Global System for Mobile communications
  • GPRS General Packet Radio Service
  • EDGE Enhanced Data Rates for GSM Evolution
  • OFDMA may be implemented in a wireless technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, Evolved UTRA (E-UTRA).
  • 2 shows examples of a WFD session.
  • 2 (a) is an audio-only session, where the WFD source may be connected to either the primary sync or the secondary sync.
  • 2 (b) is a video-only session, where the WFD source is connected to the primary sink.
  • 2 (c) is an audio and video session.
  • 2 (d) illustrates a session connection in the case of a coupled WFD Sink operation.
  • the primary sync can render the video and the secondary sync can render the audio, respectively.
  • the primary sync can render both the video and the audio.
  • Such a session may be established after performing a procedure as shown in FIG. 3. Specifically, the WFD Device Discovery (S401), WFD Service Discovery (S402), WFD Connection Setup (S403), Capability Exchange and Negotiation (S404) procedures are described. After performing, a session may be established. Hereinafter, this will be described sequentially.
  • the WFD source may find a peer device for the WFD, that is, a WFD sink, through WFD device discovery.
  • the WFD devices may include a WFD Information Element (IE) in a beacon, a probe request frame, and a probe response frame.
  • the WFD IE is an information element including information related to the WFD, such as a device type and a device state, which will be described later.
  • the WFD device may transmit a probe response frame including its own WFD IE in response thereto.
  • the probe request frame may include a WFD IE, a Wi-Fi Simple Configuration (WSC) IE, and a P2P information element.
  • WSC Wi-Fi Simple Configuration
  • the probe response frame which is a response thereto, is transmitted through a channel through which the probe request frame is received, and may include all of P2P IE, WSC IE, and WFD IE.
  • 4 illustrates a device discovery and service discovery process defined in WFDS 1.0.
  • the WFD source and / or the WFD sink that performed the WFD device discovery may discover the service capability of each other, if necessary. Specifically, when one WFD device transmits a service discovery request frame in which the WFD capability is included as an information subelement, the other WFD device responds to the service in which its WFD capability is included as an information subelement.
  • the search response frame may be transmitted.
  • the probe request frame and the response frame used in the device discovery procedure may include information indicating whether the WFD device has the capability of supporting the service discovery procedure.
  • FIG. 5 shows a process for the seeker to discover a device and a service through UDP.
  • both devices When both devices are connected to an AP, they open a specific port (or ASP Coordination Protocol port). This port allows the ASP to broadcast discovery request packets throughout the subnet.
  • the advertiser may match a corresponding service, store information about the device and the service, and transmit a discovery response to the unicast through the AP.
  • the WFD device that performs the WDF device discovery and optionally the WFD service discovery procedure may select a WDF device for WFD connection setup.
  • the WFD connection may use a connectivity scheme of one of Wi-Fi P2P and TDLS.
  • the WFD devices may determine the connection scheme based on the preferred connectivity information and the associated BSSID sub-element carried with the WFD information element.
  • 6 (a) and 6 (b) show a connection using Wi-Fi P2P and a connection using TDLS.
  • the AP may be common to or different from the WFD source and the WFD sink. Alternatively, the AP may not exist.
  • the WFD source and the WFD sink must maintain connection with the AP, as shown in FIG. 6 (b).
  • the WFD device may proceed with the WFD capability exchange and negotiation.
  • WFD capability exchange and negotiation may be performed by exchanging messages using the Real-Time Streaming Protocol (RTSP).
  • RTSP Real-Time Streaming Protocol
  • WFD capability exchange and negotiation may be by exchange of RTSP M1 to RTSP M4 messages as shown in FIG. 7.
  • the WFD source may transmit an RTSP M1 (Request) message for starting the RTSP procedure and the WFD capability negotiation (S801).
  • the RTSP M1 request message may include an RTSP OPTIONS request for determining an RTSP method set supported by the WFD sink.
  • the WFD sink may transmit an RTSP M1 response message in which RTSP methods supported by the WFD sink are enumerated (S802).
  • the WFD sink may transmit an RTSP M2 request message for determining an RTSP method set supported by the WFD source (S803).
  • the WFD source may respond with an RTSP M2 response message in which RTSP methods supported by the WFD source are enumerated (S804).
  • the WFD source may transmit an RTSP M3 request message (RTSP GET_PARAMETER request message) specifying a list of WFD capabilities to be known (S805).
  • RTSP M3 request message specifying a list of WFD capabilities to be known (S805).
  • the WFD sink may respond with an RTSP M3 response message (RTSP GET_PARAMETER response message).
  • the WFD source may determine an optimal parameter set to be used during the WFD session and transmit an RTSP M4 request message (RTSP SET_PARAMETER request message) including the determined parameter set to the WFD sink (S806).
  • the WFD sink may transmit an RTSP M4 response message (RTSP SET_PARAMETER response message) (S806).
  • the WFD devices that have performed the WFD capability exchange and negotiation may establish a WFD session through the procedure shown in FIG. 8.
  • the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink (S901).
  • the WFD sink may respond with an RTSP M5 response message.
  • the WFD sink may send an RTSP SETUP request message (RTSP M6 request) to the WFD source.
  • RTSP M6 request When the RTSP M6 request message is received, the WFD source may respond with an RTSP SETUP response message (RTSP M6 response). If the status code of the RTSP M6 response message indicates 'OK', the RTSP session may have been successfully established.
  • the WFD sink may send an RTSP PLAY request message (RTSP M7 request) to the WFD source to indicate that it is ready to receive the RTP stream.
  • the WFD source may respond with an RTSP PLAY response message (RTSP M7 response).
  • RTSP M7 response the status code 'OK' of the RTSP PLAY response message indicates that the WFD session was established successfully.
  • the WFD source may perform an RTSP M3 request message (RTSP GET_PARAMETER request message), AV (Audio / Video) format update, to obtain the capability for at least one RTSP parameter supported by the WFD sink to the WFD sync.
  • RTSP M4 request message for setting at least one RTSP parameter value corresponding to the WFD session, for triggering capability renegotiation between the WFD source and the WFD sink, triggering the WFD sink to send an RTSP PAUSE request message (RTSP M9 request message) RTSP M5 request message, RTSP M12 request message indicating that the WFD source enters WFD Standby mode, RTSP M14 request message or UIBC to select input type, input device and other parameters to be used in UIBC.
  • An RTSP M15 request message for enabling or disabling may be transmitted to the WFD sink.
  • the WFD sink that has received the enumerated RTSP request message from the WFD source may respond with an RTSP response message.
  • RTSP M7 request messages RTSP PLAY request messages
  • RTSP M9 request messages 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.
  • An RTSP M15 request message or the like for disabling may be transmitted to the WFD source.
  • the WFD source receiving the above-listed RTSP request message from the WFD sink may respond with an RTSP response message.
  • the WFD source and the WFD sink may proceed with audio / video streaming using a codec commonly supported by both.
  • a codec commonly supported by the WFD source and the WFD sink it is possible to ensure interoperability between the two.
  • WFD communication is based on the WFD IE, and the frame format of the WFD IE is shown in Table 1 below.
  • the WFD IE is composed of an Element ID field, a Length field, a WFD-specific OUI field, an OUI type field indicating the type / version of the WFD IE, and a WFD subelement field similarly to the conventional P2P IE.
  • the WFD subelement field has a format as shown in Table 2 below.
  • Subelement ID (Decimal) Notes 0 WFD Device Information One Associated BSSID 2 WFD Audio Formats 3 WFD Video Formats 4 WFD 3D Video Formats 5 WFD Content Protection 6 Coupled Sink Information 7 WFD Extended Capability 8 Local IP Address 9 WFD Session Information 10 Alternative MAC Address 11-255 Reserved
  • the subelement ID field of one octet indicates what information this WFD subelement includes. Specifically, the values 0, 1,... Of the subelement ID field. 10, each of these subelements is a WFD Device Information subelement, Associated BSSID subelement, WFD Audio Formats subelement, WFD Video Formats subelement, WFD 3D Video Formats subelement, WFD Content Protection subelement, Coupled Sink Information subelement, WFD Extended Capability subelement, Local IP Address subelement, WFD Session Information subelement, or alternative MAC address subelement.
  • the WFD Device Information subelement includes information necessary for determining whether to attempt pairing with a WFD device and session creation.
  • the Associated BSSID subelement is used to indicate the address of the currently associated AP.
  • the WFD Audio Formats subelement, the WFD Video Formats subelement, and the WFD 3D Video Formats subelement are used to indicate capabilities of the WFD device related to audio, video, and 3D video, respectively.
  • the WFD Content Protection subelement delivers information related to the content protection scheme, and the Coupled Sink Information subelement carries information about the state of the coupled sink, MAC address, and the like.
  • the WFD Extended Capability subelement is used to convey various capability information of other WFD devices, and the Local IP Address subelement is used to deliver an IP address to the WFD peer during TDLS setup.
  • the WFD Session Information subelement contains information such as a list of WFD device information descriptors in the WFD group, and if the WFD connection scheme requires an interface (for example, a MAC address) different from that used in device discovery, the Alternative MAC Address subelement. Can convey relevant information.
  • the Subelement body field includes detailed information of the subelement corresponding to the subelement ID.
  • the subelement body field includes a WFD Device Information subfield including information about the WFD device and a Session indicating TCP port information for receiving an RTSP message, as illustrated in Table 3 below. It may include a Management Control Port subfield and a WFD Device Maximum Throughput subfield which is information on the maximum average yield.
  • WFD Device Information 2 See Table 5 Session Management Control Port 2 Valid TCP port Default 7236. TCP port at which the WFD Device listens for RTSP messages. (If a WFD Sink that is transmitting this subelement does not support the RTSP server function, this field is set to all zeros.)
  • the WFD Device can choose any value other than default 7236.
  • WFD Device Maximum Throughput 2 Maximum average throughput capability of the WFD Device represented in multiples of 1Mbps
  • Coupled Sink Operation Support at WFD Sink bit 0b0 Coupled Sink Operation not supported by WFD Sink 0b1: Coupled Sink Operation supported by WFD Sink This bit is valid for WFD Device Type bits set to value 0b01, 0b10 or 0b11. When WFD Device Type bits value is 0b00, the value of this b3 is ignored upon receiving.
  • a first device supporting Wi-Fi Direct Service may transmit a service discovery request to a second device through an AP (S901).
  • a service discovery response transmitted by the second device may be received from the AP.
  • the first device may transmit a frame related to the transmission mode negotiation to the second device (S903).
  • a transmission mode capability check for the ASP coordination protocol may be performed.
  • the first device may transmit a frame related to a transport mode negotiation (eg, a transport mode for ASP request), and receive a response (eg, an ACK) (S904).
  • the first device may receive a response frame (Transport mode for ASP response, S905) for the frame related to the transport mode negotiation from the second device, and transmit a response (for example, ACK, S906). Thereafter, the verdict check process (S907 to S9010) may be performed.
  • the transmission mode negotiation succeeds through a frame related to transmission mode negotiation
  • the first device may transmit a session request frame using the transmission mode in which negotiation is successful (S911).
  • the frame related to transmission mode negotiation may include a list of supportable (transmission modes), and may further include information on a preferred transmission mode.
  • the second device may select and respond to a plurality of devices, in which case it must listen in a separate transport mode.
  • the transmission mode may be one of User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Media Access Control (MAC). That is, the transmission mode negotiation may be understood as a negotiation process on which transmission mode, UDP, TCP, or MAC, a session is established.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • MAC Media Access Control
  • the transmission mode negotiation may be understood as a negotiation process on which transmission mode, UDP, TCP, or MAC, a session is established.
  • a transport mode that can be supported through ASP may be included.
  • the frame related to the transmission mode negotiation is composed of a MAC header, a frame body and a 32-bit CRC field (FCS field), as shown in Fig. 10 or 11 (802.11 standard) ) May be a data frame.
  • the frame body may include a Logical Link Control (LLC) field, a Sub-Network Access Protocol (SNAP) field, a payload type field, and a payload field.
  • LLC Logical Link Control
  • SNAP Sub-Network Access Protocol
  • payload type field e.g., a payload type field
  • the frame body may include a payload type field indicating an ASP. This uses 801.11 data frames to support ASP. Unique identifiers can be declared to support ASP for SNAP and Payload Types.
  • the payload type field may include the contents of Table 6 below.
  • Protocol name Payload type Subcluse Remote Request / Response One 12.10.3 (Remote Request / Response frame definition)
  • TDLS 2 10.23.2 (TDLS payload)
  • FST (11ad) 3 10.33.5 (FST payload (11ad))
  • the payload field may include a transport mode bitmap field indicating one of UDP, TCP, and MAC. That is, the payload field may include content corresponding to Table 7 below.
  • the transport mode bitmap may be set as shown in Table 8 below.
  • UDP UDP transport for ASP coordination protocol
  • MAC MAC transport for ASP coordination protocol
  • TCP TCP transport for ASP coordination protocol
  • the above-described frame format is transmitted in the form of data frames in the WLAN infrastructure, there may be frame loss.
  • normal transmission and reception confirmation may use the ACK / NACK message format defined in the ASP coordination protocol.
  • the ASP coordination protocol format can be reused, and only transport mode bitmap information can be defined and used.
  • the device A and the device B may enter a connection setup step.
  • the PD Requester may transmit Feature Capability information through the PD request frame.
  • the Feature Capability information may add a preferred transmission mode / supportable method (transmission mode) to the Feature Capability P2P Info attribute.
  • the PD Responder may select a transmission mode preferred by the service or the ASP and include the information in the Feature Capability P2P Info attribute to respond using the PD response frame.
  • the PD Requester may send a Fail message as an event.
  • Priority for transport mode may be used. You can also set the default transport mode.
  • Default Transport mode if there is no Feature Capability P2P Info attribute in PD response frame, PD requester is regarded as Default Transport mode.
  • the default transport mode may be determined by one of the methods described in the Feature Description of the PD request in Table 9. Table 9 can be used in combination with two or more transport modes.
  • PD Requester Feature Capability PD Requester: Feature Description PD Responder: Valid Feature Capability ASP Action Coordination Protocol Transport Bitmask 0x0001-0x00FF Bit (s) inoframton 0x01: UDP Transport 0x02: MAC0x03: TCP Transport0x04-0x80: Reserved for future transports. You can choose one of them and send it. Both ASPs involved in this PD exchange shall use the transport indicated in the PD response for all ASP coordination protocol messaging between the two ASPs. 0 UDP Transport One MAC 2 TCP Transport 3-7 reserved 0x0100-0xFF00 Reserved for future use
  • the PD Requester can be configured as a value / index / string in the form of a bitmap with a combination of features that can be supported.
  • PD Responder you can select Valid Feature Capability to configure information in the form of value / string / index / bit / bitmap and transmit it through PD Response frame.
  • FIG. 12 (b) illustrates a method of defining a separate feature capability request / response (defined as a new action frame).
  • Information on feature capability can be shared in advance, and a common feature capability can be selected to request and respond.
  • the pre-sharing method may add a feature capability field at the time of device / service discovery, or may be added to be mandatory for service_information. Alternatively, the information may be shared between devices at the time of PD request / response.
  • Device / Service Discovery Request / Response may use the frame format of FIG. 12.
  • payload can be used by combining the information shown in Table 10 below.
  • Service_ID is a value using SHA-256, etc., and may be used in whole or in part.
  • the first device Device B, layer 2 and layer 3 connections are established after the first device is connected to the AP.
  • the Service layer of the first device transmits a SeekService () method to the ASP layer (S1001).
  • the first device broadcasts a discovery request to a subnet through the ASP layer (S1002). Since there is no peer providing a service corresponding to the discovery request, a response cannot be received.
  • the second device which is an advertiser, may receive a discoverable notification transmitted by the first device (S1006).
  • the searchable notification may include information on a service supported by the second device for transmitting the searchable notification. Accordingly, it may be determined whether the service known through the searchable notification is a service that the first device finds. If the service found by the first device matches the service known through the searchable notification, the first device may transmit a discovery request (S1007) or a SearchResult () to the service layer (S1009). The first device may transmit the discovery request S1007 in one of broadcast or unicast. After the discovery request is received by the AP, the AP may broadcast it back to the subnet. When the discovery request is received by the second device, the second device may receive a discovery response as a response (S1008).
  • S1007 discovery request
  • S1009 SearchResult
  • knowing the details of the service can inform the user that there is a device supporting the service currently available in the network. This may be performed by the ASP layer transmitting SearchResult () to the service layer (S1009), and displaying the notification to the user (S1010).
  • the first device broadcasts a discovery request for service discovery on a currently connected connection. However, if the second device does not start the current service or does not advertise currently, the second device does not respond to the discovery request. (After a time elapses), the second device Device A, which is an advertiser, may receive a discoverable notification transmitted by the first device.
  • the searchable notification may be transmitted immediately after the second device connects to the subnet when the second device operates as a service advertisement.
  • the discoverable notification may be broadcast by the second device as soon as the second device connects to the network. That is, in FIG. 10, the second device transmits an association request to the AP (S1003), establishes an L2 / L3 connection, and then transmits a searchable notification to the AP (S1005).
  • the AdvertiseService () method is shown to be called after the network connection, but may be called before the network.
  • the searchable notification may include an IP header, a user datagram protocol (UDP) header, and a UDP datagram. That is, the searchable notification may be packetized by UDP (or TCP) and generated / delivered on the IP. This packet can be defined as ASP Coordination Protocol or a new UDP discovery protocol.
  • FIG. 11 shows an embodiment when the searchable notification is defined as an ASP Coordination Protocol (CP CP).
  • the UDP datagram may include an Opcode field, a sequence number field, and a payload field.
  • the Opcode value may indicate what message, and as illustrated in FIG. 11, it may indicate that opcode 9 is a searchable notification.
  • the UDP datagram may include one or more Type Length Value (TLV) fields.
  • TLV Type Length Value
  • the searchable notification message is a UDP packet that can be broadcast to a subnet, and may be to broadcast a service supported by the device to the network when the device joins the network.
  • all attributes may be included in the Information Element (IE) TLV field of the searchable notification in the TLV form in the Information Element (IE) defined in the P2P standard and the WFDS standard.
  • IE Information Element
  • attributes defined in the WFA and attribute types to be included in future IE may be included in the IE TLVs field.
  • it may include an advertised service information attribute defined in the WFDS P2P addendum spec.
  • Figure 13 illustrates a searchable notification procedure according to another embodiment of the present invention.
  • the discovery request and / or discovery response procedure is not performed.
  • the service seeker may not require a discovery request and a discovery response process. That is, the service seeker may send a service SearchResult () event to the service using only the searchable notification message, and notify the user that the new service search is completed.
  • FIG. 10 and 13 illustrate an example in which the searchable notification transmitted by the second device provides a service that the first device is looking for.
  • FIG. 14 relates to a case in which the searchable notification does not provide a service that the first device is looking for.
  • the service seeker may not send a discovery request and / or a SearchResult to a higher service even if the service seeker receives the searchable notification message.
  • the Seeker initially searched for a service called 'org.wi-fi.wfds.send.rx', that is, a file transfer receiving service.
  • a service seeker does not need to inform a higher level service of a service search result.
  • the service advertiser supports the service.
  • FIG. 14 is a block diagram illustrating a configuration of a wireless device according to an embodiment of the present invention.
  • the wireless device 10 may include a processor 11, a memory 12, and a transceiver 13.
  • the transceiver 13 may transmit / receive a radio signal, for example, may implement a physical layer according to the IEEE 802 system.
  • the processor 11 may be electrically connected to the transceiver 13 to implement a physical layer and / or a MAC layer according to the IEEE 802 system.
  • the processor 11 may be configured to perform one or more operations of an application, service, and ASP layer according to various embodiments of the present invention described above, or may be configured to perform an operation related to an apparatus operating as an AP / STA. .
  • a module for implementing the operation of the wireless device according to various embodiments of the present invention described above may be stored in the memory 12 and executed by the processor 11.
  • the memory 12 may be included in the processor 11 or installed outside the processor 11 and connected to the processor 11 by a known means.
  • 16 is a diagram illustrating still another configuration of a wireless device for an embodiment of the present invention.
  • the RF transceiver 21 transfers information generated in the PHY protocol module 22 to the RF spectrum, performs filtering / amplification, etc. to transmit an antenna, or transmits an RF signal received from the antenna to the PHY protocol module. It moves to the band that can be processed and handles the processes such as filtering. Such a switching function for switching the functions of transmission and reception may also be included.
  • the PHY protocol module 22 performs the process of inserting additional signals such as FEC encoding and modulation, preamble, pilot, and the like for data required for transmission by the MAC protocol module 23 and delivers them to the RF transceiver. It performs the function of delivering data to MAC protocol module through the process of demodulation, equalization, FEC decoding and removal of added signal from PHY layer.
  • the PHY protocol module may include a modulator, demodulator equalizer, FEC encoder, FEC decoder, and the like.
  • the MAC protocol module 23 performs a necessary process for transferring and transmitting data transmitted from an upper layer to the PHY protocol module, and is responsible for additional transmissions for basic communication. To this end, it processes the data required for transmission in the upper layer, processes it to be transmitted and transmitted to the PHY protocol module, and processes the received data transmitted in the PHY protocol module and delivers it to the upper layer. It is also responsible for handling the communication protocol by taking care of any additional transmission and reception necessary for this data transfer.
  • Embodiments of the present invention described above may be implemented through various means.
  • embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.
  • a method according to embodiments of the present invention may include one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), and Programmable Logic Devices (PLDs). It may be implemented by field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs Application Specific Integrated Circuits
  • DSPs Digital Signal Processors
  • DSPDs Digital Signal Processing Devices
  • PLDs Programmable Logic Devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • the method according to the embodiments of the present invention may be implemented in the form of a module, a procedure, or a function that performs the functions or operations described above.
  • the software code may be stored in a memory unit and driven by a processor.
  • the memory unit may be located inside or outside the processor, and may exchange data with the processor by various known means.

Landscapes

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

Abstract

La présente invention concerne, dans un mode de réalisation, un procédé par lequel un premier dispositif destiné à prendre en charge un service direct de Wi-Fi (WFDS) établit une session de plateforme de service d'application (ASP) avec un second dispositif. Le procédé d'établissement de session comprend les étapes consistant à : émettre, vers un second dispositif, une demande de découverte de service par l'intermédiaire d'un AP ; recevoir, de la part de l'AP, une réponse de découverte de service émise par le second dispositif ; émettre, vers le second dispositif, une trame se rapportant à une négociation de mode d'émission ; et émettre une trame de demande de session à l'aide d'un mode d'émission qui a réussi dans la négociation, si la négociation du mode d'émission est réussie à travers le cadre se rapportant à la négociation du mode d'émission.
PCT/KR2016/001307 2015-02-05 2016-02-05 Procédé et dispositif pour établir une session dans un système de communication sans fil WO2016126138A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562112604P 2015-02-05 2015-02-05
US62/112,604 2015-02-05

Publications (1)

Publication Number Publication Date
WO2016126138A1 true WO2016126138A1 (fr) 2016-08-11

Family

ID=56564380

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/001307 WO2016126138A1 (fr) 2015-02-05 2016-02-05 Procédé et dispositif pour établir une session dans un système de communication sans fil

Country Status (1)

Country Link
WO (1) WO2016126138A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120155350A1 (en) * 2010-11-19 2012-06-21 Qualcomm Incorporated Probe messaging for direct link connections
WO2014069868A1 (fr) * 2012-10-29 2014-05-08 엘지전자 주식회사 Procédé de communication de services directs en wifi au moyen d'une nfc, et dispositif correspondant
US20140196125A1 (en) * 2013-01-04 2014-07-10 Qualcomm Incorporated Deploying wireless docking as a service
WO2014171956A1 (fr) * 2013-04-17 2014-10-23 Intel Corporation Techniques permettant d'utiliser une plateforme de services d'application (asp) de services directs wi-fi (wfds) pour des services de couche 2
US20140351444A1 (en) * 2013-05-22 2014-11-27 Emily H. Qi Systems and methods for enabling service interoperability functionality for wifi direct devices connected to a network via a wireless access point

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120155350A1 (en) * 2010-11-19 2012-06-21 Qualcomm Incorporated Probe messaging for direct link connections
WO2014069868A1 (fr) * 2012-10-29 2014-05-08 엘지전자 주식회사 Procédé de communication de services directs en wifi au moyen d'une nfc, et dispositif correspondant
US20140196125A1 (en) * 2013-01-04 2014-07-10 Qualcomm Incorporated Deploying wireless docking as a service
WO2014171956A1 (fr) * 2013-04-17 2014-10-23 Intel Corporation Techniques permettant d'utiliser une plateforme de services d'application (asp) de services directs wi-fi (wfds) pour des services de couche 2
US20140351444A1 (en) * 2013-05-22 2014-11-27 Emily H. Qi Systems and methods for enabling service interoperability functionality for wifi direct devices connected to a network via a wireless access point

Similar Documents

Publication Publication Date Title
WO2014088378A1 (fr) Procédé et dispositif permettant une initialisation de session dans un système de communication sans fil
WO2014123383A1 (fr) Procédé et appareil pour établir une session dans un système de communication sans fil
WO2014109513A1 (fr) Procédé et dispositif de recherche dans un système de communication sans fil
WO2015152657A1 (fr) Procédé et appareil pour émettre-recevoir un signal par un terminal de réseautage sensible au voisinage (nan) dans un système de communication sans fil
WO2015167269A1 (fr) Procédé et dispositif de découverte de service dans un système de communication sans fil
EP3128718B1 (fr) Procédé de découverte de service, et dispositif
KR101838079B1 (ko) 무선 통신 시스템에서 디스커버리를 수행하는 방법 및 장치
KR20160026866A (ko) 직접 통신 시스템에서 디바이스 탐색 방법 및 이를 위한 장치
WO2017039376A1 (fr) Procédé et dispositif permettant l'échange d'informations de capacité de connexion dans un système de communication sans fil
WO2014129844A1 (fr) Procédé permettant de trouver un instrument pour communication poste à poste (p2p) directement en wi-fi et appareil associé
WO2017014579A1 (fr) Procédé et appareil de réalisation de découverte dans un système de communication sans fil
WO2015119329A1 (fr) Procédé et dispositif destinés à effectuer une découverte dans un système de communication sans fil
WO2017018823A1 (fr) Procédé et dispositif permettant de former une session de plate-forme de service d'application dans un système de communication sans fil
US10051673B2 (en) Method and apparatus for session initiation in wireless communication system
WO2016148523A1 (fr) Procédé et dispositif pour exécuter une recherche de service dans un système de communication sans fil
WO2020085539A1 (fr) Procédé d'établissement d'une session de service d'homologue à homologue sur une liaison d'infrastructure
WO2014010962A1 (fr) Schéma pour découverte de dispositif et formation de groupe p2p
WO2016148550A1 (fr) Procédé et appareil permettant d'établir une session de plateforme de service d'application dans un système de communication sans fil
WO2017155271A1 (fr) Procédé et appareil pour recevoir une diffusion en continu par l'intermédiaire d'un protocole de transport dans un système de communication sans fil
KR101901951B1 (ko) 무선 통신 시스템에서 와이파이 다이렉트를 지원하는 장치가 디스커버리를 수행하는 방법 및 장치
WO2016126138A1 (fr) Procédé et dispositif pour établir une session dans un système de communication sans fil
WO2016126148A1 (fr) Procédé et appareil pour l'établissement de session dans un dispositif d'affichage wi-fi
WO2016048065A1 (fr) Procédé et dispositif par lesquels une source de wfd transmet et reçoit un signal concernant un écran double dans un système de communication sans fil
WO2017105071A1 (fr) Procédé et dispositif permettant d'exécuter une découverte de service via nfc dans un système de communications sans fil
WO2017007183A1 (fr) Procédé de régulation de puissance dans un système de communications sans fil et dispositif associé

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

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

Country of ref document: EP

Kind code of ref document: A1