WO2016126138A1 - Method and device for establishing session in wireless communication system - Google Patents

Abstract

One embodiment of the present invention provides a method by which a first device for supporting a WiFi direct service (WFDS) establishes an application service platform (ASP) session with a second device, the session establishing method comprising the steps of: transmitting, to a second device, a service discovery request through an AP; receiving, from the AP, a service discovery response transmitted by the second device; transmitting, to the second device, a frame relating to a transmission mode negotiation; and transmitting a session request frame by using a transmission mode which has succeeded in negotiation, if the transmission mode negotiation is successful through the frame relating to the transmission mode negotiation.

Description

Method and apparatus for establishing session in wireless communication system

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.

Recently, with the development of information and communication technology, various wireless communication technologies have been developed. Among these, 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.

It is a direct communication technology that allows devices to easily connect with each other without a wireless access point (AP) basically required in a conventional WLAN system. Wi-Fi Direct or Wi-Fi P2P (peer) The introduction of -to-peer) is under discussion. According to 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.

Recently, various Wi-Fi supporting devices are used, and among them, the number of Wi-Fi Direct supporting devices that can communicate between Wi-Fi devices without an AP is increasing. The WFA (Wi-Fi Alliance) introduces a platform that supports various services (eg, Send, Play, Display, Print, etc.) using the Wi-Fi Direct link. Technology is under discussion. This may be referred to as Wi-Fi Direct Service (WFDS). According to the WFDS, applications, services, and the like may be controlled or managed by a service platform called an application service platform (ASP).

Standards for WLAN technology are being developed by the Institute of Electrical and Electronics Engineers (IEEE) 802.11 group. 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.

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). In QBSS, not only non-AP (AP) STAs but also APs are QAPs (Quality APs) that support QoS. However, in the currently commercialized 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. As a result, even in the currently commercialized wireless LAN environment, even if the QSTA, there is a limit that can not use the DLS service.

Tunneled Direct Link Setup (TDLS) is a newly proposed wireless communication protocol to overcome this limitation. Although 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. Hereinafter, a wireless network supporting such a TDLS is called a TDLS wireless network.

Conventional 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. In this case, the devices in the network are connected through the AP, not directly with each other.

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. Hereinafter, Wi-Fi Direct based communication is referred to as Wi-Fi D2D communication (simply, D2D communication) or Wi-Fi P2P communication (simply, P2P communication). In addition, the 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. In addition, 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. Specifically, in P2P communication, 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. Here, the signal transmission path directly established between the two WFDS devices may be limited to the data transmission path. For example, 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.) include 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).

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

FIG. 1 is a diagram for describing a Wi-Fi Direct Service (WFDS) framework component.

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. Below the Wi-Fi Direct layer, 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.

Above the ASP, a service layer is defined. The service layer contains use case specific services. WFA defines four basic services: Send, Play, Display, and Print. In addition, 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.

Although 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. For example, in this document, 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. Fi Docking) or a service for supporting Neighbor Awareness Networking (NAN).

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.

The present invention is to provide a transmission mode according to the capability.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

According to an embodiment of the present invention, in a method in which a first device supporting WiFi Direct Servicea (WFDS) establishes an application service platform (ASP) session with a second device, 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.

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

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.

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.

According to the present invention, a customized transmission mode can be used for each STA through the ASP platform.

The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

BRIEF DESCRIPTION OF THE DRAWINGS The drawings appended hereto are for the purpose of providing an understanding of the present invention and for illustrating various embodiments of the present invention and for describing the principles of the present invention together with the description of the specification.

1 is a diagram illustrating an exemplary structure of a WFDS system.

2 shows examples of a WFD session.

3 is a diagram for explaining procedures required for establishing a WFD session.

4 illustrates a WFDS device / service discovery procedure.

5 shows discovery via UDP.

6 shows a WFD connection topology.

7 is a diagram for explaining WFD capability exchange and negotiation.

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.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art appreciates that the present invention may be practiced without these specific details.

The following embodiments combine the components and features of the present invention in a predetermined form. 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. In addition, 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.

Specific terms used in the following description are provided to help the understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.

In some instances, well-known structures and devices are omitted or shown in block diagram form, centering on the core functions of each structure and device, in order to avoid obscuring the concepts of the present invention. In addition, the same components will be described with the same reference numerals throughout the present specification.

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.

The following techniques include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and the like. It can be used in various radio access systems. 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). 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. As in the case of FIG. 2 (b), only a primary sync is possible for a WFD sync connected to a WFD source. 2 (d) illustrates a session connection in the case of a coupled WFD Sink operation. In such a case, the primary sync can render the video and the secondary sync can render the audio, respectively. Alternatively, 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.

WFD  Device discovery

The WFD source may find a peer device for the WFD, that is, a WFD sink, through WFD device discovery.

For 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. Here, 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. When the WFD device receives the probe request frame including the WFD IE, the WFD device may transmit a probe response frame including its own WFD IE in response thereto. If the WFD device is associated with the infrastructure AP and operates as a Wi-Fi P2P device, the probe request frame may include a WFD IE, a Wi-Fi Simple Configuration (WSC) IE, and a P2P information element. 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.

Information related to WFD device discovery not mentioned in the above description may be in accordance with the 'Wi-Fi Display Technical Specification' and / or the 'Wi-Fi Peer-to-Peer (P2P) Technical Specification Wi-Fi Direct Service Addendum' document. This also applies to the following descriptions.

WFD  Service discovery

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. In order to perform the service discovery procedure, 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.

5 shows a process for the seeker to discover a device and a service through UDP. 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. Upon receiving the advertiser, 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.

WFD  connect set up

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. After selecting a WFD device for WFD connection setup according to a policy or user input, 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. In FIG. 6A, the AP may be common to or different from the WFD source and the WFD sink. Alternatively, the AP may not exist. When performing a WFD connection using TDLS, the WFD source and the WFD sink must maintain connection with the AP, as shown in FIG. 6 (b).

WFD  Ability exchange and negotiation

If WFD connection setup is performed between WFD devices, the WFD device may proceed with the WFD capability exchange and negotiation. Through the WFD capability negotiation, at least one of the codec, the codec profile information, the codec level information, and the resolution information supported by the WFD source and the WFD sink are transmitted to the WFD device. WFD capability exchange and negotiation may be performed by exchanging messages using the Real-Time Streaming Protocol (RTSP). In addition, it is possible to determine a parameter set that defines the audio / video payload during the WFD session. WFD capability exchange and negotiation may be by exchange of RTSP M1 to RTSP M4 messages as shown in FIG. 7.

In detail, 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. Receiving the RTSP M1 request message, the WFD sink may transmit an RTSP M1 response message in which RTSP methods supported by the WFD sink are enumerated (S802).

Subsequently, the WFD sink may transmit an RTSP M2 request message for determining an RTSP method set supported by the WFD source (S803). When the RTSP M2 request message is received, 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). When the RTSP M3 request message is received, the WFD sink may respond with an RTSP M3 response message (RTSP GET_PARAMETER response message).

Based on the RTSP M3 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). Upon receiving this, the WFD sink may transmit an RTSP M4 response message (RTSP SET_PARAMETER response message) (S806).

WFD  Session establishment

The WFD devices that have performed the WFD capability exchange and negotiation may establish a WFD session through the procedure shown in FIG. 8. In detail, the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink (S901). In response, the WFD sink may respond with an RTSP M5 response message.

If the RTSP M5 message including the trigger parameter SETUP is successfully exchanged, the WFD sink may send an RTSP SETUP request message (RTSP M6 request) to the WFD source. 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.

After successful exchange of RTSP M6 messages, 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). Here, the status code 'OK' of the RTSP PLAY response message indicates that the WFD session was established successfully. After the WFD session is established, 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.

Subsequently, the WFD Sink will continue to perform RTSP M7 request messages (RTSP PLAY request messages) to start (or resume) audio / video streaming, and RTSP M9 request messages (RTSP) to suspend audio / video streaming from the WFD source to the WFD sink. 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. Enable or deactivate the UISP M12 request message, the M13 request message requesting the WFD source to refresh the IDR, the input type to be used in UIBC, the input device and other parameters, or the UIBC to select UIBC. 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.

When a WFD session is established and audio / video streaming starts, the WFD source and the WFD sink may proceed with audio / video streaming using a codec commonly supported by both. By using a codec commonly supported by the WFD source and the WFD sink, it is possible to ensure interoperability between the two.

WFD  Information Element

WFD communication is based on the WFD IE, and the frame format of the WFD IE is shown in Table 1 below.

Field	Size (octets)	Value (Hexadecimal)	Description
Element ID	One	DD	IEEE 802.11 vendor specific usage
Length	One	Variable	Length of the following fields in the IE in octets. The length field is variable and set to 4 plus the total length of WFD subelements.
OUI	3	50-6F-9A	WFA Specific Organizationally Unique Identifier (OUI)
OUI Type	One	0A	Identifying the type or version of the WFD IE. Setting to 0x0A indicates WFA WFD v1.0
WFD subelements	Variable		One or more WFD subelements appear in the WFD IE

As shown in Table 1, 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.

Field	Size (octets)	Value (Hexadecimal)	Description
Subelement ID	One		Identifying the type of WFD subelement. (Refer to Table 3 for specific values)
Length	2	Variable	Length of the following fields in the subelement
Subelements body field	Variable		Subelement specific information fields

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. Here, 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.

Subsequently, the Subelement body field includes detailed information of the subelement corresponding to the subelement ID. For example, in the case of the WFD Device Information subelement, 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.

Field	Size (octets)	Value	Description
Subelement ID	One	0	Identifying the type of WFD subelement. (Refer to Table 3 for specific values)
Length	2	6	Length of the following fields of the subelement.
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

Bits	Name	Interpretation
1: 0	WFD Device Type bits	0b00: WFD Source 0b01: Primary Sink 0b10: Secondary Sink 0b11: dual-role possible, i.e., either a WFD Source or a Primary Sink
2	Coupled Sink Operation Support at WFD Source bit	0b0: Coupled Sink Operation not supported by WFD Source. 0b1: Coupled Sink Operation supported by WFD SourceThis bit is valid for WFD Device Type bits set to value 0b00 or 0b11. When WFD Device Type bits value is 0b01 or 0b10, the value of this b2 is ignored upon receiving.
3	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.
5: 4	WFD Session Availability bits	0b00: Not available for WFD Session0b01: Available for WFD Session0b10, 0b11: Reserved
6	WSD Support bit	0b0: WFD Service Discovery (WSD): Supported
7	PC bit	0b0: Preferred Connectivity (PC): P2P0b1: Preferred Connectivity (PC): TDLS
8	CP Support bit	0b0: Content Protection using the HDCP system 2.0 / 2.1: Not supported
9	Time Synchronization Support bit	0b1: Time Synchronization using 802.1AS: Supported
10	Audio un-supported at Primary Sink bit	0b0: all cases except below 0b1: If B1B0 = 0b01 or 0b11, and this WFD Device does not support audio rendering when acting as a Primary Sink
11	Audio only support at WFD Source bit	0b0: all cases except below 0b1: If B1B0 = 0b00 or 0b11, and this WFD Device supports transmitting audio only elementary stream when acting as a WFD Source

Hereinafter, a session establishment method according to an embodiment of the present invention will be described based on the above description.

Example  One

Referring to FIG. 9, a first device supporting Wi-Fi Direct Service (WFDS) may transmit a service discovery request to a second device through an AP (S901). In operation S902, 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). Thereafter, a transmission mode capability check for the ASP coordination protocol may be performed. In detail, 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. When 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.

In the above description, 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. Here, in addition to UDP, TCP, and MAC, a transport mode that can be supported through ASP may be included.

Looking at the frame related to the transmission mode negotiation in more detail, 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. For example, 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. As a frame format for transmitting an ASP Coordination Protocol frame, LLC (3 Octets): 1 for DSAP, 1 for SSAP, 1 for Control, SNAP (5 Octets): 3 for WFA OUI, 2 for ASP can be set. 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))
ASP	4	xxx
Reserved	5-255

Subsequently, 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.

Field	Size (octets)	Value	Description
Opcode	One	0x ??
Sequence Number	One	Variable
Transport mode bitmap	One	variable	0x01: UDP0x02: MAC0x03: TCP0x4 ~ 0xFF: Reserved

The transport mode bitmap may be set as shown in Table 8 below.

Bit (s)	Information
0	UDP	The UDP field shall be set 1 if the ASP device supports UDP transport for ASP coordination protocol, and is set to 0 otherwise
One	MAC	The MAC field shall be set 1 if the ASP device supports MAC transport for ASP coordination protocol, and is set to 0 otherwise
2	TCP	The TCP field shall be set 1 if the ASP device supports TCP transport for ASP coordination protocol, and is set to 0 otherwise
3-7	Reserved

Since the above-described frame format is transmitted in the form of data frames in the WLAN infrastructure, there may be frame loss. To compensate for this, normal transmission and reception confirmation may use the ACK / NACK message format defined in the ASP coordination protocol. In the above description, the ASP coordination protocol format can be reused, and only transport mode bitmap information can be defined and used.

Example  2

Referring to FIG. 12 (a), when the device A and the device B exchange P2P Probe Request / Response and P2P Service Discovery Request / Response, and then select a desired device, the device A and the device B may enter a connection setup step. At this time, when ConnectSessions () is called in the ASP method, the PD Requester may transmit Feature Capability information through the PD request frame. Here, 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. At this time, if the PD Responder does not include the Feature Capability P2P Info attribute in 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. In case of using 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. In 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.

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.

12 (c) illustrates a method of performing a process of explicitly sharing Feature capability Info. First.

In the description of the first embodiment, Device / Service Discovery Request / Response may use the frame format of FIG. 12. At this time, 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.

Device / Service Discovery Request / Response	Note
Service Name / Service_ID
Service status	Available2. Or not
Preferred band
Operating bands	2.4 GHz 2. 5 GHz 3. 60 GHz
Network Type for ASP	UDP2. MAC3. TCP
Network type for service	UDP2. MAC3. TCP
Service information	Service info. Provided by a service
Connectivity method	WLAN Infrastructure2. P2P3. BT

13 illustrates a discovery procedure according to an embodiment of the present invention. First, from the standpoint of the seeker, 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. In this state (after time elapses), the second device, which is an advertiser, may receive a discoverable notification transmitted by the first device (S1006).

Here, 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). After receiving the discovery response, 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).

10 shows another embodiment of the present invention. The same applies to the case where the first device B and the second device A already have a Wi-Fi Direct connection. As shown in FIG. 10, 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.

In the above description, the searchable notification may be transmitted immediately after the second device connects to the subnet when the second device operates as a service advertisement. Alternatively, 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). In FIG. 10, the AdvertiseService () method is shown to be called after the network connection, but may be called before the network.

In the above description, 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). As illustrated in FIG. 11, the UDP datagram may include an Opcode field, a sequence number field, and a payload field. Here, 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. An example of this is shown in FIG. 12. As described above, 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. For such a searchable notification message, 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. In addition to the P2P specification, attributes defined in the WFA and attribute types to be included in future IE may be included in the IE TLVs field. In particular, 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. In the procedure illustrated in FIG. 13, unlike in FIG. 12, the discovery request and / or discovery response procedure is not performed. If the searchable notification message includes enough information to initialize the service in the IE TLV field, 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.

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. In contrast, FIG. 14 relates to a case in which the searchable notification does not provide a service that the first device is looking for. In detail, 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. For example, the Seeker initially searched for a service called 'org.wi-fi.wfds.send.rx', that is, a file transfer receiving service. In the case of supporting a print reception service, a service seeker does not need to inform a higher level service of a service search result.

According to the embodiment of the present invention described above, even if the service seeker already connected to the network does not perform a separate Seek operation (passive), the service advertiser supports the service.

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. In addition, 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. . In addition, 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.

Specific configuration of the wireless device 10 of FIG. 14 may be implemented so that the above-described matters described in various embodiments of the present invention may be independently applied or two or more embodiments may be applied at the same time. Omit.

16 is a diagram illustrating still another configuration of a wireless device for an embodiment of the present invention.

Referring to FIG. 16, 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. To this end, 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. For example, embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.

For implementation in hardware, 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.

In the case of an implementation by firmware or software, 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.

The detailed description of the preferred embodiments of the invention disclosed as described above is provided to enable any person skilled in the art to make and practice the invention. Although the above has been described with reference to the preferred embodiments of the present invention, those skilled in the art will variously modify and change the present invention without departing from the spirit and scope of the invention as set forth in the claims below. I can understand that you can. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Various embodiments of the present invention as described above have been described with reference to the IEEE 802.11 system, but can be applied to various mobile communication systems in the same manner.

Claims (14)

1. In a method for a first device supporting WiFi Direct Servicea (WFDS) to establish an Application Service Platform (ASP) session with a second device,

   Sending, via the AP, a service discovery request to a second device;

   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;

   When the transmission mode negotiation is successful through the frame related to the transmission mode negotiation, transmitting a session request frame using the transmission mode in which the negotiation is successful;

   Session establishment method comprising a.
2. The method of claim 1,

   The transmission mode is one of User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Media Access Control (MAC).
3. The method of claim 2,

   The frame related to the transmission mode negotiation is a data frame consisting of a MAC header, a frame body and a 32-bit CRC field.
4. The method of claim 3,

   The frame body includes a payload type field indicating an ASP.
5. The method of claim 3,

   The frame body includes a Logical Link Control (LLC) field, a Sub-Network Access Protocol (SNAP) field, a payload type field, and a payload field.
6. The method of claim 5,

   The payload field includes a transport mode bitmap field indicating one of the UDP, TCP, and MAC.
7. The method of claim 1,

   And a frame related to the transmission mode negotiation is transmitted through the AP.
8. In the first device that supports the WiFi Direct Service (WFDS), and establishes an Application Service Platform (ASP) session with the second device,

   Transceiver; And

   A processor;

   Including;

   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 a frame related to a transmission mode negotiation to the second device. And when the transmission mode negotiation is successful through the frame related to the transmission mode negotiation, transmitting the session request frame using the transmission mode in which the negotiation is successful.
9. The method of claim 8,

   The transmission mode is one of the User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Media Access Control (MAC).
10. The method of claim 9,

    The frame related to the transmission mode negotiation is a data frame consisting of a MAC header, a frame body and a 32-bit CRC field.
11. The method of claim 10,

    And the frame body includes a payload type field indicating an ASP.
12. The method of claim 10,

    The frame body includes a Logical Link Control (LLC) field, a Sub-Network Access Protocol (SNAP) field, a payload type field, and a payload field.
13. The method of claim 12,

    The payload field includes a transport mode bitmap field indicating one of the UDP, TCP, and MAC.
14. The method of claim 8,

    And the frame related to the transmission mode negotiation is transmitted through the AP.

Images