WO2019203414A1 - Procédé de transmission de trame de multidiffusion dans un système lan sans fil comprenant une pluralité de sous-réseaux, et terminal sans fil utilisant ce procédé - Google Patents

Procédé de transmission de trame de multidiffusion dans un système lan sans fil comprenant une pluralité de sous-réseaux, et terminal sans fil utilisant ce procédé Download PDF

Info

Publication number
WO2019203414A1
WO2019203414A1 PCT/KR2018/015164 KR2018015164W WO2019203414A1 WO 2019203414 A1 WO2019203414 A1 WO 2019203414A1 KR 2018015164 W KR2018015164 W KR 2018015164W WO 2019203414 A1 WO2019203414 A1 WO 2019203414A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
router
wfd
subnet
multicast service
Prior art date
Application number
PCT/KR2018/015164
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 WO2019203414A1 publication Critical patent/WO2019203414A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming

Definitions

  • the present disclosure relates to wireless communication, and more particularly, to a method for transmitting a multicast frame in a WLAN system including a plurality of subnets, and a wireless terminal using the same.
  • Wireless display transmission technology is a technology that allows the image of the mobile device to be viewed on a large screen TV (television) or monitor.
  • Wireless display transmission technology can be largely divided into a content transmission method and a mirroring method (that is, screen casting).
  • the content transmission method converts a screen of a mobile device into a signal and then transmits the converted signal to a remote device.
  • a content file is streamed to a remote device to simultaneously display an image of the mobile device on the remote device.
  • the mirroring method has the advantage of being able to wirelessly transmit pixel information of the original screen without being dependent on a specific service.
  • Miracast can be understood as a wireless video transmission standard and wireless display transmission technology created by the WiFi Alliance. Miracast may also be understood as one type following a mirroring scheme.
  • An object of the present specification is to provide a method for transmitting a multicast frame in a WLAN system including a plurality of subnets with improved performance and a wireless terminal using the same.
  • a source terminal combined with a first AP of a first subnet may provide a dedicated group address for searching for a multicast service.
  • Sending a subscription request message comprising a first router via a first AP to a first router for a first subnet;
  • the source terminal transmits a multicast service query frame for the second subnet to the first router via the first AP, wherein a first time to live (TTL) value of the multicast service query frame is greater than a preset minimum value.
  • TTL time to live
  • a method for transmitting a multicast frame in a WLAN system including a plurality of subnets having improved performance and a wireless terminal using the same may be provided.
  • FIG. 1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.
  • FIG. 2 is an exemplary block diagram illustrating a WFD network.
  • FIG. 3 is an exemplary conceptual diagram illustrating a WFD session.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • FIG. 6 is a conceptual diagram illustrating a procedure for WFD capability exchange negotiation.
  • FIG. 7 is a conceptual diagram illustrating a procedure for establishing a WFD session.
  • FIG. 8 is a diagram illustrating a WFD connection based on a Wi-Fi infrastructure between a WFD source and a WFD sink according to an exemplary embodiment.
  • FIG. 9 is a conceptual diagram illustrating a conventional problem associated with transmission of a multicast frame.
  • 10 is a flowchart showing a DNS-SD procedure through a Wi-Fi infrastructure.
  • FIG. 11 is a conceptual diagram illustrating a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • FIGS. 12 and 13 are flowcharts illustrating a method of performing a service discovery procedure in a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • 14A and 14B are flowcharts illustrating a method for transmitting a multicast frame in a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • 16 is a block diagram illustrating a wireless device to which an embodiment can be applied.
  • 17 is a block diagram illustrating an example of an apparatus included in a processor.
  • FIG. 1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.
  • an IEEE 802.11 architecture may be composed of a plurality of components, and a wireless LAN system supporting transparent STA mobility to upper layers by their interaction may be provided in a wireless local system. area network, hereinafter referred to as "WLAN").
  • WLAN wireless local system. area network
  • the Basic Service Set may be a basic building block of an IEEE 802.11 LAN.
  • BSS Basic Service Set
  • BSS1 and BSS2 may exist and each BSS may include two STAs.
  • STA1 and STA2 may be included in BSS1
  • STA3 and STA4 may be included in BSS2.
  • the STA means a device that operates according to the Medium Access Control (MAC) / PHY (Physical) specification of IEEE 802.11.
  • a station (STA) may include an access point (AP) STA (simply an AP) and a non-AP STA.
  • the AP corresponds to a device that provides a network (eg, WLAN) connection to a non-AP STA through an air interface.
  • the station may be called various names such as a (wireless LAN) device.
  • the AP may be configured in a fixed or mobile form and may include a portable wireless device (eg, laptop computer, smart phone, etc.) that provides a hot spot.
  • AP is a base station (BS), Node-B, Evolved Node-B (eNB), Base Transceiver System (BTS), femto base station in other wireless communication fields (Femto BS) or the like.
  • BS base station
  • eNB Evolved Node-B
  • BTS Base Transceiver System
  • Femto base station in other wireless communication fields
  • Non-AP STAs generally correspond to devices that a user directly handles, such as laptop computers, PDAs, wireless modems, and smart phones.
  • the non-AP STA includes a terminal, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal, a mobile subscriber station. (Mobile Subscriber Station, MSS) and the like.
  • WTRU wireless transmit / receive unit
  • UE user equipment
  • MS mobile station
  • MS mobile terminal
  • MSS Mobile Subscriber Station
  • an ellipse representing a BSS may be understood to represent a coverage area where STAs included in each BSS maintain communication. This area may be referred to as a basic service area (BSA).
  • BSA basic service area
  • IBS independent BSS
  • the IBSS may have a minimal form consisting of only two STAs.
  • BSS (BSS1 or BSS2) of FIG. 1 is the simplest form and can be understood as a representative example of IBSS. This configuration is possible when STAs can communicate directly.
  • this type of LAN is not configured in advance, but may be configured when a LAN is required. This type of LAN may be referred to as an ad-hoc network.
  • the AP may be responsible for a physical layer support function for a wireless / wired connection, a routing function for devices on a network, a function of adding / removing a device to a network, and a service providing function. That is, in the existing WLAN system, devices in a network are connected through APs, but not directly connected to each other.
  • Wi-Fi Direct As a technology for supporting direct connection between devices, a Wi-Fi Direct (WFD) standard is defined.
  • Wi-Fi Direct (WFD) is a direct communication technology that allows devices (or STAs) to easily connect with each other without an access point basically required in a conventional WLAN system.
  • WFD Wi-Fi Direct
  • WFD Wi-Fi Direct
  • Wi-Fi Direct is also called Wi-Fi P2P.
  • Wi-Fi P2P adds support for direct device-to-device communication while retaining most of the functionality of the existing Wi-Fi standard. Therefore, there is an advantage in that the device equipped with the Wi-Fi chip (chip) can fully utilize hardware and physical characteristics, and provide P2P communication between devices mainly by upgrading software functions.
  • P2P group there is a device that plays the role of an AP in an existing infrastructure network.
  • the device In the P2P specification, the device is called a P2P group owner (hereinafter referred to as 'P2P GO').
  • P2P group owner hereinafter referred to as 'P2P GO'.
  • P2P clients may exist around P2P GO. Only one P2P GO can exist in one P2P group, and all other devices become client devices.
  • Wi-Fi Alliance provides various services using the Wi-Fi Direct link (e.g., Send, Play, Display, Print, etc.).
  • Wi-Fi Direct link e.g., Send, Play, Display, Print, etc.
  • WFDS Wi-Fi Direct Service
  • an application may be controlled or managed by an application service platform (hereinafter referred to as 'ASP').
  • the WFDS devices supported by the WFDS may include devices supporting a WLAN system such as a display device, a printer, a digital camera, a projector, and a smartphone.
  • the WFDS device may include a STA and an AP. WFDS devices in the WFDS network may be directly connected to each other.
  • the WFD standard is defined for transferring audio / video (AV) data between devices while satisfying high quality and low latency.
  • WFD networks (WFD sessions) with the WFD standard allow Wi-Fi devices to connect to each other in a peer-to-peer manner without going through a home network, office network, or hot-spot network. Can be.
  • WFD devices in the WFD network may search for information about the WFD devices (for example, capability information), establish a WFD session, and render content through the WFD session.
  • a WFD session may be a network between a source device that provides content and a sink device that receives and renders the content.
  • the source device may be referred to as a WFD source.
  • a sink device may be referred to as a WFD sink.
  • the WFD source may mirror data present on the display (or screen) of the WFD source to the display of the WFD sink.
  • the WFD source and the WFD sink may perform a device discovery and service discovery procedure by exchanging a first sequence message between each other.
  • an internet protocol hereinafter, referred to as 'IP'
  • 'IP' internet protocol
  • TCP transmission control protocol
  • RTSP real time streaming protocol
  • RTP real time protocol
  • a capability negotiation procedure between the WFD source and the WFD sink may be performed via RTSP.
  • the WFD source and the WFD sink may exchange RTSP based messages (ie, M1 through M4) during the capability negotiation procedure. Thereafter, the WFD source and the WFD sink may exchange WFD session control messages.
  • a data session via RTP may be established between the WFD source and the WFD sink.
  • User datagram protocol UDP may be used for data transport in a WFD network.
  • FIG. 2 is an exemplary block diagram illustrating a WFD network.
  • the WFD source 200 and the WFD sink 250 may be connected as a WFD device based on a specific connection scheme (eg, WiFi-P2P scheme).
  • a specific connection scheme eg, WiFi-P2P scheme.
  • the WFD source 200 of FIG. 2 may be a device that supports streaming of multimedia content through a P2P link.
  • the WFD sink 250 may be a device that performs a procedure (ie, performs a rendering procedure) of generating an image and / or sound based on multimedia content received from the WFD source 200 through a P2P link. have.
  • the WFD sink 250 of FIG. 2 may be a primary sink or a secondary sink.
  • the secondary sync may render only the audio payload from the WFD source 200.
  • FIG. 3 is an exemplary conceptual diagram illustrating a WFD session.
  • the WFD source 300 of FIG. 3 may be connected to the primary sink 305 or the secondary sink 310 based on an audio-only session.
  • the WFD source 320 may be connected to the primary sink 325 based on a video-only session.
  • the WFD source 340 may be connected to the primary sink 345 based on an audio and video session.
  • FIG. 3 a session connection according to a coupled WFD Sink operation is shown.
  • the primary sink 365 can render the video and the secondary sink 370 can render the audio.
  • primary sync 365 may render both video and audio.
  • various types of WFD sessions shown in FIG. 3 may be established after performing a procedure to be described with reference to FIG. 4.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • a WFD session may be established between the WFD source and the WFD sink.
  • the WFD source may perform a WFD device discovery procedure to find a peer device (ie, WFD sink) for the WFD.
  • a peer device ie, WFD sink
  • the beacon frame, the probe request frame, and the probe response frame transmitted by the WFD source and the WFD sink for the WFD device discovery procedure may include a WFD information element (IE).
  • the WFD IE may include information associated with the WFD, such as a device type or a device state.
  • the WFD source may transmit a probe request frame including the WFD IE to the WFD sink.
  • the WFD sink may transmit a probe response frame including the WFD IE in response to the probe request frame.
  • the probe request frame may include both WFD IE and P2P information elements.
  • the probe response frame which is a response to the probe request frame, may be transmitted through the same channel in which the probe request frame is received.
  • the probe response frame may include both a P2P IE and a WFD IE.
  • the discovery of the service capability between the WFD source and the WFD sink that performed the discovery of the WFD device may be performed.
  • the WFD service discovery procedure may be an optional procedure.
  • a WFD source sends a service discovery request frame that contains information about WFD capabilities
  • the WFD sink sends a service discovery response frame that contains information about WFD capabilities in response to the service discovery request frame. Can be.
  • the WFD device may select a WFD device (eg, WFD sink) for WFD connection setup.
  • a WFD device eg, a WFD sink
  • a specific connection scheme eg Wi-Fi P2P or Tunneled Direct Link Setup, hereinafter 'TDLS'
  • Wi-Fi P2P or Tunneled Direct Link Setup hereinafter 'TDLS'
  • the WFD device may establish a connectivity scheme based on preferred connectivity information and an associated basic service set identifier subelement carried by the WFD Information Element (WFD IE). You can decide.
  • WFD IE WFD Information Element
  • step S404 of FIG. 4 a capability exchange procedure and a negotiation procedure may be performed between the WFD source and the WFD sink. Operation S404 will be described in more detail with reference to FIG. 6 to be described later.
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • the WFD source 500 may be connected to the WFD sink 510 based on a Wi-Fi P2P link.
  • the WFD source 500 and the WFD sink 510 may be combined with the same AP.
  • the WFD source 500 and the WFD sink 510 may be combined with different APs.
  • the WFD source 500 and the WFD sink 510 may not be combined with a separate AP.
  • the source 550 may be connected to the WFD sink 560 based on the TDLS link.
  • the WFD source 550 when a WFD connection is made using a TDLS link, the WFD source 550 must maintain a connection with the AP coupled with the WFD source 550.
  • the WFD sink 560 when the WFD connection is performed using the TDLS link, the WFD sink 560 must maintain a connection with the AP coupled with the WFD sink 560.
  • an AP to which the WFD source 550 maintains a connection and an AP to which the WFD sink 560 maintains a connection may be the same.
  • Wi-Fi Direct ie, P2P
  • TDLS link a TDLS link
  • the WFD capability exchange and negotiation procedure may be performed after the WFD connection setup procedure between WFD devices.
  • the WFD source and the WFD sink may exchange at least one or more of the codec, the profile information, the codec level information, and the resolution information supported by each other.
  • WFD capability exchange and negotiation may be performed by exchanging messages using the Real Time Streaming Protocol (RTSP).
  • RTSP Real Time Streaming Protocol
  • a set of parameters for defining the audio / video payload may be determined.
  • the WFD capability exchange and negotiation procedure may be performed by exchange of RTSP M1 to RTSP M4 messages.
  • FIG. 6 is a conceptual diagram illustrating a procedure for WFD capability negotiation.
  • FIG. 6 is described on the premise that L3 connectivity is successfully completed after the procedure mentioned with reference to FIG. 4 is performed. That is, one IP address may be allocated for the WFD source and the WFD sink of FIG. 6.
  • the WFD source may send an RTSP M1 request message to start the RSTP procedure and WFD capability negotiation.
  • the RTSP M1 request message may include an RTSP OPTIONS Request.
  • the WFD sink may transmit an RTSP M1 response message in which the RTSP methods supported by the WFD sink are enumerated.
  • the RTSP M1 response message may include an RTSP OPTIONS Response.
  • the WFD sink may transmit an RTSP M2 request message for determining a set of RTSP methods supported by the WFD source.
  • the RTSP M2 request message may include an RTSP OPTIONS Request.
  • the WFD source may respond with an RTSP M2 response message that lists the RTSP methods supported by the WFD source.
  • the RTSP M2 response message may include an RTSP OPTIONS Response.
  • the WFD source may transmit an RTSP M3 request message to query the attributes of the WFD sink and the capabilities of the WFD sink.
  • the RTSP M3 request message may include an RTSP GET_PARAMETER Request.
  • the RTSP M3 request message may explicitly specify a list of capabilities of the WFD sink that the WFD source wants to acquire from the WFD sink.
  • the WFD sink may respond with an RTSP M3 response message.
  • the RTSP M3 response message may include an RTSP GET_PARAMETER Response.
  • the RTSP M3 response message may include values of parameters of the WFD sink requested according to the RTSP M3 request message.
  • the WFD source may determine the optimal set of parameters to be used during the WFD session based on the RTSP M3 response message.
  • the WFD source may transmit an RTSP M4 request message including the determined parameter set to the WFD sink.
  • the RTSP M4 request message may include an RTSP SET_PARAMETER Request.
  • the WFD sink may respond with an RTSP M4 response message.
  • the RTSP M4 response message may include an RTSP SET_PARAMETER Response.
  • FIG. 7 is a conceptual diagram illustrating a procedure for WFD session establishment. 1 to 7, FIG. 7 is described on the premise that steps S601 to S608 are performed in advance.
  • the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink.
  • RTSP M5 Trigger SETUP request an RTSP SET parameter request message
  • the WFD sink may transmit an RTSP M5 response message to the WFD source in response to the RTSP SET parameter request message.
  • step S703 if the RTSP M5 message including the trigger parameter setting (SETUP) is exchanged successfully, the WFD sink may transmit the RTSP SETUP request message (RTSP M6 request) to the WFD source.
  • SETUP trigger parameter setting
  • the WFD source may transmit an RTSP SETUP response message (RTSP M6 response) to the WFD sink.
  • RTSP M6 response For example, the establishment of a status code included in the RTSP M6 response message may indicate the successful establishment of an RTSP session.
  • step S705 after the successful exchange of the RTSP M6 message, the WFD sink may transmit an RTSP PLAY request message (RTSP M7 request message) to the WFD source to inform that it is ready to receive the RTP stream.
  • RTSP M7 request message RTSP PLAY request message
  • the WFD source may transmit an RTSP PLAY response message to the WFD sink.
  • successful establishment of the WFD session may be indicated based on the status code included in the RTSP PLAY response message.
  • the WFD source can be used to update the RTSP M3 request message (RTSP GET_PARAMETER request message) to obtain the capability of at least one RTSP parameter supported by the WFD sink to the WFD sync, and to update the audio / video format.
  • RTSP M3 request message RTSP GET_PARAMETER request message
  • RTSP M4 request message to set at least one RTSP parameter value corresponding to the WFD session for capability renegotiation between WFD source and WFD sink, RTSP triggering the WFD sink to send RTSP PAUSE request message (RTSP M9 request message) M5 request message, RTSP M12 request message indicating that the WFD source enters WFD standby mode, RTSP M14 request message to select input type, input device and other parameters to be used in user input back channel (UIBC).
  • RTSP M15 request message for enabling or disabling a user input back channel (UIBC) may be transmitted to the WFD sink. .
  • the WFD sink receiving the aforementioned RTSP request message from the WFD source may respond with an RTSP response message.
  • the WFD Sink will request an RTSP M7 request message (RTSP PLAY request message) to start (or resume) audio / video streaming, and an RTSP M9 request message to suspend audio / video streaming from the WFD source to the WFD sink RTSP PAUSE request message), RTSP M10 request message to request the WFD source to change the audio rendering device, RTSP M11 request message to instruct to change the active connector type, WFD sink has entered WFD standby mode.
  • RTSP M12 request message indicating the message, M13 request message requesting the WFD source to refresh the instantaneous decoding refresh (IDR), RTSP M14 request message to select the input type to be used in UIBC, input device and other parameters or activation of UIBC.
  • RTSP M15 request messages can be sent to the WFD source for enable or disable. .
  • the WFD source receiving the above-listed RTSP request message from the WFD sink may respond with an RTSP response message.
  • the WFD source and the WFD sink can proceed with audio / video streaming using a codec commonly supported by both.
  • a codec commonly supported by the WFD source and the WFD sink By using a codec commonly supported by the WFD source and the WFD sink, interoperability between the two can be guaranteed.
  • FIG. 8 is a diagram illustrating a WFD connection based on a Wi-Fi infrastructure between a WFD source and a WFD sink according to an exemplary embodiment.
  • a WFD device when a WFD device is connected to an IP network based on a Wi-Fi infrastructure, the corresponding WFD device is based on service discovery based on mDNS / DNS-SD (multicast Domain Name System / DNS Service Discovery). The procedure can be performed.
  • mDNS / DNS-SD multicast Domain Name System / DNS Service Discovery
  • FIG. 9 is a conceptual diagram illustrating a conventional problem associated with transmission of a multicast frame.
  • the first subnet network sub # 1 of FIG. 9 may include a first sink terminal 911 and a source terminal 912 coupled with the first AP 910. In addition, the first subnet network sub # 1 may be associated with the L3 router 930.
  • the IP address for the first subnet network sub # 1 may be implemented based on C class based on IPv4.
  • the IP address of the source terminal 912 may be assigned to 192.168.1.1.
  • the second subnet network sub # 2 of FIG. 9 may include a second sink terminal 921 coupled with the second AP 920.
  • the second subnet network sub # 2 may be associated with the L3 router 930.
  • the IP address for the second subnet network sub # 2 may be implemented based on C class based on IPv4.
  • the IP address of the second sink terminal 921 may be assigned to 192.168.2.1.
  • a time to live (TTL) value of a packet transmitted to the L3 router may be set to a minimum value.
  • the TTL value of the multicast packet may be decreased by '1'. For example, if the TTL value of the multicast packet is set to the minimum value, the TTL value of the multicast packet cannot be reduced. In this case, multicast packets cannot be delivered to other L3 routers.
  • the source terminal 912 may transmit a multicast service discovery packet.
  • a multicast scheme or a broadcast scheme may be applied to the multicast service discovery packet.
  • the multicast service discovery packet may be delivered to the first sink terminal 911 included in the first subnet network sub # 1.
  • the multicast service discovery packet referred to herein may include an mDNS query message or an mDNS response message, which will be described later.
  • the TTL value of the mDNS service discovery packet may be set to a minimum value. Accordingly, the mDNS service discovery packet cannot be delivered to a subnet network other than the first subnet network sub # 1. In other words, the mDNS service discovery packet cannot be delivered to the second sink terminal 921 included in the second subnet network sub # 2.
  • FIG. 10 is a flowchart showing a DNS-SD procedure through a Wi-Fi infrastructure.
  • the service discovery procedure through the Wi-Fi infrastructure may be performed based on mDNS / DNS-SD.
  • mDNS / DNS-SD supports self-assigned link local addressing, unique link local host naming, and service discovery to support zeroconf networking. The same three functions can be covered.
  • a unique host name for a device assigned an IP address in a local network may be resolved in a service discovery procedure through a Wi-Fi infrastructure.
  • DNS-SD a publication operation for service discovery, a discovery operation for browsing for services, and an instance name are resolved to an IP address and a port number.
  • Three operations may be supported, such as a resolution operation.
  • a service may be registered by an application in order to publish the service.
  • a PTR (pointer) record may be generated.
  • SRV service
  • TXT text
  • a registered DNS record may be utilized to discover a list of instance names.
  • a service search may be performed based on a PTR record lookup for a matching service type.
  • the service discovery operation may be performed by mapping a list of service names and instance names of corresponding service names using the PTR record.
  • the instant name of the service can be resolved to a host name and an IP address.
  • SRV record lookup may be performed by the application using the instant name of the service.
  • the mDNS responder may respond based on an SRV record that includes the host name and port number of the service instance.
  • the host name may then be determined by the application as an IP address. And, using the service on a specific port can be started by the application.
  • the WFD source terminal 1010 may be connected to the AP 1000.
  • a WFD source terminal 1010 that is a Seeker may act as an active subscriber.
  • the WFD sink terminal 1020 which is an advertiser, may be connected to the AP 1000.
  • the WFD sink terminal 1020 may act as a solicited advertiser.
  • the service may be registered with the WFD sink terminal 1020 that is generated and cached PTR record, SRV record and TXT recorder.
  • the WFD source terminal 1010 uses a standard multicast address (ie, 224.0.0.251 for IPv4, FF02: FB for IPv6), and mDNS for PTR record lookup on UDP port 5353.
  • the query may be sent to the Wi-Fi infrastructure network through the AP 1000.
  • MDNS queries for PTR record lookups include the PTR record name ("_display._tcp.local").
  • the mDNS query may indicate that the WFD source terminal 1010 retrieves a list of instance names corresponding to a service type corresponding to “_display._tcp”.
  • the WFD sink terminal 1020 receiving the mDNS query on the Wi-Fi infrastructure network may perform service type matching corresponding to "_display._tcp". Only devices that match the service type may respond with an mDNS response.
  • the mDNS response may include a PTR record that provides an instance name of a device whose service type matches.
  • the application of the WFD source terminal 1010 may extract the instance name from the PTR record. In addition, the application of the WFD source terminal 1010 may provide a user with a list of instance names corresponding to the discovered advertiser devices.
  • the user can select the advertiser device from an on-screen list.
  • a WFD sink terminal 1020 having an instance name of “Sink2” is selected.
  • the WFD source terminal 1010 may send an mDNS query to the selected WFD sink terminal 1020 to obtain a TXT record and an SRV record associated with the instance name of the selected advertiser device.
  • the WFD sink terminal 1020 may include the SRV record, TXT record, and all address records in the mDNS response. That is, the WFD sink terminal 1020 corresponding to "Sink2_display._tcp.local" may respond with an mDNS response including an SRV record and a TXT record.
  • the application of the WFD source terminal 1010 may initiate a WFD session.
  • FIG. 11 is a conceptual diagram illustrating a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • a first subnet may be associated with a first router 1110 # 1.
  • the first subnet may include a first router 1110 # 1, a first AP 1120 # 1, a second AP 1120 # 2, and first to fourth STAs STA # 1 to STA # 4. It may include.
  • the first AP 1120 # 1 and the second AP 1120 # 2 included in the first subnet may be configured to have the same Service Set Identifier (SSID).
  • the first STA (STA # 1) and the second STA (STA # 2) may be combined with the first AP 1120 # 1.
  • the third STA (STA # 3) and the fourth STA (STA # 4) may be combined with the second AP 1120 # 2.
  • the second subnet may be associated with the second router 1110 # 2.
  • the second subnet may include a second router 1110 # 2, a third AP 1120 # 3, a fourth AP 1120 # 4, and fifth to eleventh STAs (STA # 5 to STA # 11). have.
  • the third AP 1120 # 3 and the fourth AP 1120 # 4 included in the second subnet may be configured to have the same SSID.
  • the fifth STA (STA # 5) to the eighth STA (STA # 8) may be combined with the third AP 1120 # 3.
  • the ninth STA (STA # 9) to the eleventh STA (STA # 11) may be combined with the fourth AP 1120 # 4.
  • FIGS. 12 and 13 are flowcharts illustrating a method of performing a service discovery procedure in a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • the WFD source terminal 1200 of FIG. 12 corresponds to the first STA (STA # 1) of FIG. 11.
  • the first to third WFD sink terminals 1200 # 1 to 1200 # 3 of FIG. 12 correspond to the fifth to seventh STAs STA # 5 to STA # 7 of FIG. 11.
  • first L3 router 1210 # 1 of FIG. 12 corresponds to the first router 1110 # 1 of FIG. 11. It may be assumed that the second L3 router 1210 # 2 of FIG. 12 corresponds to the second router 1110 # 2 of FIG. 11.
  • the WFD source terminal 1200, the first AP 1220 # 1, and the first L3 router 1210 # 1 are included in the first subnet. It may be understood that the first to third WFD sink terminals 1200 # 1 to 1200 # 3, the second L3 router 1210 # 2, and the second AP 1220 # 2 are included in the second subnet.
  • first AP 1220 # 1 of FIG. 12 may correspond to the first AP 1020 # 1 of FIG. 11.
  • the second AP 1220 # 2 of FIG. 12 may correspond to the third AP 1020 # 3 of FIG. 10.
  • the WFD source terminal 1200 of FIG. 12 may be understood as a wireless terminal combined with the first AP 1120 # 1 of FIG. 11.
  • the first to third WFD sink terminals 1200 # 1 to 1200 # 3 of FIG. 12 may be understood as a wireless terminal combined with the third AP 1120 # 3 of FIG. 11.
  • a dedicated group address of a multicast discovery group for multicast service discovery may be predefined.
  • the source terminal 1200 transmits an Internet Group Management Protocol (IGMP) join request message including a dedicated group address of a multicast discovery group for multicast service discovery. It may transmit to the first L3 router 1210 # 1 via 1).
  • IGMP Internet Group Management Protocol
  • the IGMP subscription response message may be received from the first L3 router 1210 # 1 via the first AP 1220 # 1 to the source terminal 1200.
  • the IGMP subscription response message may include information for approving the subscription of the source terminal 1200 to the multicast discovery group.
  • a plurality of sink terminals 1200 # 1 to 1200 # 3 may be sequentially subscribed to a multicast discovery group.
  • the first sink terminal 1200 # 1 for performing the multicast service discovery sends an IGMP join request message including the dedicated group address of the multicast discovery group for the multicast service discovery to the second AP 1220 #. It can be delivered to the second L3 router 1210 # 2 via 2).
  • the IGMP subscription response message may be received from the second L3 router 1210 # 2 through the second AP 1220 # 2 to the first sink terminal 1200 # 1. .
  • the IGMP subscription response message may include information for approving the subscription of the first sink terminal 1200 # 1 to the multicast discovery group.
  • the second sink terminal 1200 # 2 for performing the multicast service discovery may send an IGMP join request message including the dedicated group address of the multicast discovery group for the multicast service discovery to the second AP 1220 # 2. ) To the second L3 router 1210 # 2.
  • an IGMP subscription response message may be received from the second L3 router 1210 # 2 via the second AP 1220 # 2 to the second sink terminal 1200 # 2.
  • the IGMP subscription response message may include information for approving the subscription of the second sink terminal 1200 # 2 to the multicast discovery group.
  • the third sink terminal 1200 # 3 for performing the multicast service discovery may send an IGMP join request message including the dedicated group address of the multicast discovery group for the multicast service discovery to the second AP 1220 #. It can be delivered to the second L3 router 1210 # 2 via 2).
  • the IGMP subscription response message may be received from the second L3 router 1210 # 2 to the third sink terminal 1200 # 3 via the second AP 1220 # 2.
  • the IGMP subscription response message may include information for approving the subscription of the third sink terminal 1200 # 3 to the multicast discovery group.
  • the WFD source terminal 1300 of FIG. 13 corresponds to the WFD source terminal 1200 of FIG. 12. It may be understood that the first to third WFD sink terminals 1300 # 1 to 1300 # 3 of FIG. 13 correspond to the first to third WFD sink terminals 1200 # 1 to 1200 # 3 of FIG. 12. It may be understood that the first to third WFD sink terminals 1300 # 1 to 1300 # 3 of FIG. 13 correspond to the fifth to seventh STAs STA # 5 to STA # 7 of FIG. 12.
  • first L3 router 1310 # 1 of FIG. 13 corresponds to the first L3 router 1210 # 1 of FIG. 12. It may be understood that the second L3 router 1310 # 2 of FIG. 13 corresponds to the second L3 router 1210 # 2 of FIG. 12.
  • the first AP 1320 # 1 of FIG. 13 may correspond to the first AP 1220 # 1 of FIG. 12. It may be understood that the second AP 1320 # 2 of FIG. 13 corresponds to the second AP 1220 # 2 of FIG. 12.
  • a multicast service discovery packet including an mDNS query message may be referred to as a multicast service query frame.
  • a multicast service discovery packet including an mDNS response message may be referred to as a multicast service response frame.
  • the multicast service query frame may be multicast or broadcast.
  • the multicast service response frame may be multicast or broadcast.
  • the multicast service query frame and the multicast service response frame may be understood as multicast frames to which the multicast scheme is applied.
  • step S1310 the WFD source terminal 1300 receives the multicast service query frame mSRV_Q including the dedicated group address of the multicast discovery group via the first AP 1320 # 1 through the first L3 router 1310 # 1. ) Can be sent.
  • the TTL value of the multicast service query frame mSRV_Q may be set to a value larger than a preset minimum value.
  • the TTL value of the multicast service query frame (mSRV_Q) transmitted by the WFD source terminal 1300 is set to a value '2' greater than the minimum value. Can be.
  • the TTL value of the corresponding packet may be decreased by '1'.
  • the TTL value of the multicast packet is set to the minimum value in order to prevent the floating phenomenon.
  • the TTL value of the multicast packet may be set to a value larger than the minimum value. Accordingly, the multicast service query frame mSRV_Q may be transferred from the first L3 router 1310 # 1 to the second L3 router 1310 # 2. In this case, the TTL value of the multicast service query frame mSRV_Q may be updated to a value TTL reduced by '1'.
  • the second L3 router 1310 # 2 may transmit the multicast service query frame mSRV_Q to at least one WFD sink terminal subscribed to the multicast discovery group. That is, the second L3 router 1310 # 2 may transmit the multicast service query frame to the first to third WFD sink terminals 1300 # 1 to 1300 # 3 via the second AP 1320 # 2. .
  • the header information of the multicast service query frame mSRV_Q received by the second L3 router 1310 # 2 may include a dedicated group address of the multicast discovery group.
  • the second L3 router 1310 # 2 may transmit the multicast service query frame mSRV_Q only to the wireless terminals subscribed to the multicast discovery group through the IGMP subscription request message.
  • the header information may correspond to a DA (Destination Address) field of the multicast service query frame mSRV_Q.
  • the first to third WFD sink terminals 1300 # 1 to 1300 # 3 of FIG. 13 are understood as the fifth to seventh STAs (STA # 5 to STA # 7) of FIG. 11 subscribed to the multicast discovery group. Can be.
  • the fifth to seventh STAs STA # 5 to STA # 7 of FIG. 11 are joined to a multicast discovery group. It can be understood as.
  • the first sink terminal 1300 # 1 receives the first multicast service response frame mSRV_R # 1 via the second AP 1320 # 2 in response to the multicast service query frame mSRV_Q. It can transmit to the 2nd L3 router 1310 # 2.
  • the TTL value of the first multicast service response frame mSRV_R # 1 may be set to a value larger than a preset minimum value.
  • the TTL value of the first multicast service response frame mSRV_R # 1 transmitted by the first sink terminal 1300 # 1 may be set to a value larger than the minimum value. Accordingly, the first multicast service response frame mSRV_R # 1 may be transferred from the second L3 router 1310 # 2 to the first L3 router 1310 # 1. In this case, the TTL value of the first multicast service response frame mSRV_R # 1 may be updated to a value TTL reduced by '1'.
  • the first L3 router 1310 # 1 may transmit the first multicast service response frame mSRV_R # 1 to the WFD source terminal 1300 joining the multicast discovery group. That is, the first L3 router 1310 # 1 may transmit the first multicast service response frame mSRV_R # 1 to the WFD source terminal 1300 via the first AP 1320 # 1.
  • the second sink terminal 1300 # 2 receives the second multicast service response frame mSRV_R # 2 via the second AP 1320 # 2 in response to the multicast service query frame mSRV_Q. It can transmit to the 2nd L3 router 1310 # 2.
  • the TTL value of the second multicast service response frame mSRV_R # 2 may be set to a value larger than a preset minimum value.
  • the TTL value of the second multicast service response frame mSRV_R # 2 transmitted by the second sink terminal 1300 # 2 may be set to a value larger than the minimum value. Accordingly, the second multicast service response frame mSRV_R # 2 may be transferred from the second L3 router 1310 # 2 to the first L3 router 1310 # 1. In this case, the TTL value of the second multicast service response frame mSRV_R # 2 may be updated to a value TTL reduced by '1'.
  • the first L3 router 1310 # 1 may transmit the second multicast service response frame mSRV_R # 2 to the WFD source terminal 1300 joining the multicast discovery group. That is, the first L3 router 1310 # 1 may transmit the second multicast service response frame mSRV_R # 2 to the WFD source terminal 1300 via the first AP 1320 # 1.
  • the third sink terminal 1300 # 3 receives the third multicast service response frame mSRV_R # 3 via the second AP 1320 # 2 in response to the multicast service query frame mSRV_Q. It can transmit to the 2nd L3 router 1310 # 2.
  • the TTL value of the third multicast service response frame mSRV_R # 3 may be set to a value larger than a preset minimum value.
  • the TTL value of the third multicast service response frame mSRV_R # 3 transmitted by the third sink terminal 1300 # 3 may be set to a value larger than the minimum value. Accordingly, the third multicast service response frame mSRV_R # 3 may be transferred from the second L3 router 1310 # 2 to the first L3 router 1310 # 1. In this case, the TTL value of the third multicast service response frame mSRV_R # 3 may be updated to a value TTL reduced by '1'.
  • the first L3 router 1310 # 1 may transmit the third multicast service response frame mSRV_R # 3 to the WFD source terminal 1300 joining the multicast discovery group. That is, the first L3 router 1310 # 1 may transmit the third multicast service response frame mSRV_R # 3 to the WFD source terminal 1300 via the first AP 1320 # 1.
  • the first to third WFD sink terminals 1300 # 1 to 1300 # 3 of FIG. 13 may include the fifth and sixth STAs STA # 5 and STA # 6 and the ninth STA of FIG. 11. 9).
  • the fifth and sixth STAs (STA # 5 and STA # 6) and the ninth STA (STA # 9) of FIG. 11 may be wireless terminals joined to the multicast discovery group.
  • the second router 1110 # 2 of FIG. 11 transmits the fifth STA (STA # 5) and the sixth STA via the multicast service query frame mSRV_Q via the third AP 1120 # 3 of FIG. 11. Can be passed to (STA # 6).
  • the second router 1110 # 2 of FIG. 11 may transmit the multicast service query frame mSRV_Q to the ninth STA (STA # 9) via the fourth AP 1120 # 4 of FIG. 11.
  • a WFD sink terminal included in a subnet having an IP address different from the WFD source may also be searched.
  • 14A and 14B are flowcharts illustrating a method for transmitting a multicast frame in a WLAN system including a plurality of subnets according to an exemplary embodiment.
  • the plurality of WFD sink terminals included in an IP subnet different from the IP subnet to which the WFD source terminal belongs may be searched. Subsequently, at least two WFD sink terminals to which the multicast data packet is targeted may be selected.
  • At least two WFD sink terminals to which a multicast data packet is targeted may be understood as a wireless terminal belonging to a multicast transmission group.
  • two WFD sink terminals that is, STA # 5 and STA # 7 of FIG. 11
  • a plurality of wireless terminals for example, STA # 5 to STA # 7 of FIG. 11
  • the first WFD sink terminal 1400 # 1 corresponds to the fifth STA (STA # 5) of FIG. 11, and the second WFD sink terminal 1400 # 2 It may be assumed that it corresponds to the seventh STA (STA # 7) of FIG. 11.
  • step S1410 a connection procedure for a plurality of WFD sink terminals (ie, 1400 # 1 and 1400 # 2) may be performed.
  • each of the plurality of WFD sink terminals ie, 1400 # 1 and 1400 # 2 may be connected to the WFD source terminal 1400.
  • a procedure for negotiating WFD capability exchange may be performed between the plurality of sink terminals (ie, 1400 # 1, 1400 # 2) and the WFD source terminal 1400.
  • the procedure for negotiating the WFD capability exchange may be understood as the process of exchanging the RTSP M1 message to the RTSP M7 message of FIGS. 6 and 7.
  • a WFD session for at least two WFD sink terminals selected through steps S1410 and S1420 may be established. That is, the streaming operation using the multicast mode may be prepared through steps S1410 and S1420.
  • a multicast transmission address may be defined such that the multicast stream can be transmitted only to the WFD sink terminals belonging to the multicast transmission group.
  • the multicast transmission address may be set to a predetermined value for the multicast transmission group.
  • the WFD source terminal 1400 may transmit an M30 RTSP SET PARAMETER request message including a multicast transmission address to the first WFD sink terminal 1400 # 1 of the multicast transmission group.
  • the first WFD sink terminal 1400 # 1 receives an M30 RTSP response message, which is a response to the M30 RTSP SET PARAMETER request message. It may transmit to the WFD source terminal 1400.
  • the WFD source terminal 1400 may transmit an M30 RTSP SET PARAMETER request message including a multicast transmission address to the second WFD sink terminal 1400 # 2 of the multicast transmission group.
  • the second WFD sink terminal 1400 # 2 receives the M30 RTSP response message, which is a response to the M30 RTSP SET PARAMETER request message. It may transmit to the WFD source terminal 1400.
  • step S1441 the first sink terminal 1400 # 1 of the multicast transmission group receives the IGMP subscription request message including the multicast transmission address obtained in step S1431 via the second AP 1420 # 2 through the second L3. It can transmit to the router 1410 # 2.
  • an IGMP subscription response message which is a response to the IGMP subscription request message, may be received from the second L3 router 1410 # 2 through the second AP 1420 # 2 to the first sink terminal 1400 # 1.
  • the IGMP subscription response message may include information for approving the subscription of the first sink terminal 1400 # 1 to the multicast transmission group.
  • step S1442 the second sink terminal 1400 # 2, which is the target of the multicast stream, receives the IGMP subscription request message including the multicast transport address obtained in step S1432 via the second AP 1420 # 2 through the second L3. It can transmit to the router 1410 # 2.
  • an IGMP subscription response message which is a response to the IGMP subscription request message, may be received from the second L3 router 1410 # 2 to the second sink terminal 1400 # 2 via the second AP 1420 # 2.
  • the IGMP subscription response message may include information for approving the subscription of the second sink terminal 1400 # 2 to the multicast transmission group.
  • all WFD sink terminals of the multicast transmission group may be ready to receive multicast streaming.
  • the WFD source terminal 1400 may perform multicast audio video (AV) streaming to the first sink terminal 1400 # 1 and the second sink terminal 1400 # 2.
  • AV audio video
  • a multicast transmission address may be set in the DA field of a packet for multicast AV streaming.
  • MAC addresses for a plurality of sink terminals of a multicast transmission group may be set.
  • 15 shows an application example according to the present embodiment. For example, you may need to share presentations with employees on other floors using Miracast mirroring services in order to have meetings with employees on different floors with different IP subnets at work.
  • various sink devices of various locations searched on a laptop may be selected to share presentation materials with employees working at different floors.
  • the laptop ie, source device
  • the laptop may attempt to connect with several selected sink devices.
  • the screen of the laptop may be mirrored to another sink device.
  • 16 is a block diagram illustrating a wireless device to which an embodiment can be applied.
  • the wireless device may be implemented as an AP or a non-AP STA as an STA capable of implementing the above-described embodiment.
  • the wireless device may correspond to the above-described user, or may correspond to a transmitting terminal for transmitting a signal to the user.
  • the wireless device of FIG. 16 includes a processor 1610, a memory 1620, and a transceiver 1630 as shown.
  • the illustrated processor 1610, memory 1620, and transceiver 1630 may be implemented as separate chips, or at least two blocks / functions may be implemented through one chip.
  • the transceiver 1630 is a device including a transmitter and a receiver. When a specific operation is performed, only one of the transmitter and the receiver may be performed, or both the transmitter and the receiver may be performed. have.
  • the transceiver 1630 may include one or more antennas for transmitting and / or receiving wireless signals.
  • the transceiver 1630 may include an amplifier for amplifying a received signal and / or a transmitted signal and a bandpass filter for transmission on a specific frequency band.
  • the processor 1610 may implement the functions, processes, and / or methods proposed herein.
  • the processor 1610 may perform an operation according to the present embodiment described above. That is, the processor 1610 may perform the operation disclosed in the embodiment of FIGS. 1 to 15.
  • the processor 1610 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, a data processing device, and / or a converter for translating baseband signals and wireless signals.
  • ASIC application-specific integrated circuit
  • Memory 1620 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.
  • ROM read-only memory
  • RAM random access memory
  • flash memory memory cards, storage media, and / or other storage devices.
  • 17 is a block diagram illustrating an example of an apparatus included in a processor.
  • FIG. 17 For convenience of description, an example of FIG. 17 is described based on a block for a transmission signal, but it is obvious that the reception signal can be processed using the block.
  • the illustrated data processor 1710 generates transmission data (control data and / or user data) corresponding to the transmission signal.
  • the output of the data processor 1710 may be input to the encoder 1720.
  • the encoder 1720 may perform coding through a binary convolutional code (BCC) or a low-density parity-check (LDPC) technique. At least one encoder 1720 may be included, and the number of encoders 1720 may be determined according to various information (eg, the number of data streams).
  • BCC binary convolutional code
  • LDPC low-density parity-check
  • the output of the encoder 1720 may be input to the interleaver 1730.
  • the interleaver 1730 performs an operation of distributing consecutive bit signals over radio resources (eg, time and / or frequency) to prevent burst errors due to fading or the like.
  • Radio resources eg, time and / or frequency
  • At least one interleaver 1730 may be included, and the number of the interleaver 1730 may be determined according to various information (eg, the number of spatial streams).
  • the output of the interleaver 1730 may be input to a constellation mapper 1740.
  • the constellation mapper 1740 performs constellation mapping such as biphase shift keying (BPSK), quadrature phase shift keying (QPSK), quadrature amplitude modulation (n-QAM), and the like.
  • the output of the constellation mapper 1740 may be input to the spatial stream encoder 1750.
  • Spatial stream encoder 1750 performs data processing to transmit a transmission signal over at least one spatial stream.
  • the spatial stream encoder 1750 may perform at least one of space-time block coding (STBC), cyclic shift diversity (CSD) insertion, and spatial mapping on a transmission signal.
  • STBC space-time block coding
  • CSS cyclic shift diversity
  • the output of the spatial stream encoder 1750 may be input to an IDFT 1760 block.
  • the IDFT 1760 block performs an inverse discrete Fourier transform (IDFT) or an inverse Fast Fourier transform (IFFT).
  • IDFT inverse discrete Fourier transform
  • IFFT inverse Fast Fourier transform
  • the output of the IDFT 1760 block is input to the Guard Interval (GI) inserter 1770, and the output of the GI inserter 1770 is input to the transceiver 1630 of FIG. 16.
  • GI Guard Interval

Landscapes

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

Abstract

Le mode de réalisation de l'invention concerne un procédé de transmission d'une trame de multidiffusion dans un système LAN sans fil comprenant une pluralité de sous-réseaux. Le procédé comprend : la transmission, par un terminal source couplé à un premier AP d'un premier sous-réseau, d'un message de demande de rattachement contenant une adresse de groupe dédiée pour une découverte de service de multidiffusion, à un premier routeur du premier sous-réseau via le premier AP ; la réception, par le terminal source, d'un message de réponse de rattachement, depuis le premier routeur via le premier AP en réponse au message de demande de rattachement ; et la transmission, par le terminal source, d'une trame d'interrogation de service de multidiffusion d'un second sous-réseau, au premier routeur via le premier AP. Une première valeur de durée de vie (TTL) de la trame d'interrogation de service de multidiffusion est configurée pour être supérieure à une valeur minimale préconfigurée, et la trame d'interrogation de service de multidiffusion est transmise à un second routeur du second sous-réseau depuis le premier routeur d'après la première valeur TTL.
PCT/KR2018/015164 2018-04-19 2018-12-03 Procédé de transmission de trame de multidiffusion dans un système lan sans fil comprenant une pluralité de sous-réseaux, et terminal sans fil utilisant ce procédé WO2019203414A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862660224P 2018-04-19 2018-04-19
US62/660,224 2018-04-19
KR10-2018-0046130 2018-04-20
KR20180046130 2018-04-20

Publications (1)

Publication Number Publication Date
WO2019203414A1 true WO2019203414A1 (fr) 2019-10-24

Family

ID=68239572

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/015164 WO2019203414A1 (fr) 2018-04-19 2018-12-03 Procédé de transmission de trame de multidiffusion dans un système lan sans fil comprenant une pluralité de sous-réseaux, et terminal sans fil utilisant ce procédé

Country Status (1)

Country Link
WO (1) WO2019203414A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100938513B1 (ko) * 2005-05-05 2010-01-25 메시네트웍스, 인코포레이티드 멀티캐스트 라우팅을 지원하는 멀티-홉 무선 통신 네트워크 및 그 네트워크를 운영하기 위한 방법
US8355355B2 (en) * 2008-05-29 2013-01-15 Thomson Licensing Method and apparatus for multicast group management
US9385949B2 (en) * 2012-12-20 2016-07-05 Mellanox Technologies Tlv Ltd. Routing controlled by subnet managers
US9634847B2 (en) * 2009-09-30 2017-04-25 At&T Intellectual Property I, L.P. Robust multicast broadcasting
US20170373867A1 (en) * 2015-04-24 2017-12-28 Fortinet, Inc. Extension of wi-fi services multicast to a subnet across a wi-fi network using software-defined networking (sdn) to centrally control data plane behavior

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100938513B1 (ko) * 2005-05-05 2010-01-25 메시네트웍스, 인코포레이티드 멀티캐스트 라우팅을 지원하는 멀티-홉 무선 통신 네트워크 및 그 네트워크를 운영하기 위한 방법
US8355355B2 (en) * 2008-05-29 2013-01-15 Thomson Licensing Method and apparatus for multicast group management
US9634847B2 (en) * 2009-09-30 2017-04-25 At&T Intellectual Property I, L.P. Robust multicast broadcasting
US9385949B2 (en) * 2012-12-20 2016-07-05 Mellanox Technologies Tlv Ltd. Routing controlled by subnet managers
US20170373867A1 (en) * 2015-04-24 2017-12-28 Fortinet, Inc. Extension of wi-fi services multicast to a subnet across a wi-fi network using software-defined networking (sdn) to centrally control data plane behavior

Similar Documents

Publication Publication Date Title
WO2021049782A1 (fr) Procédé et appareil de fourniture d'une politique d'équipement utilisateur dans un système de communication sans fil
WO2012060611A2 (fr) Procédé de recherche de dispositif et dispositif de communication l'utilisant
WO2019164268A1 (fr) Procédé de connexion sans fil dans un système de réseau local sans fil et dispositif sans fil l'utilisant
WO2020226360A1 (fr) Appareil et procédé destinés à prendre en charge une horloge de référence de temps d'arrivée de rafale sur la base d'informations d'aide à la communication sensibles au temps dans un réseau de communication sans fil
WO2014088378A1 (fr) Procédé et dispositif permettant une initialisation de session dans un système de communication sans fil
WO2016171527A1 (fr) Procédé et appareil pour effectuer une inscription auprès d'un serveur de mandataire nan dans un système de communications sans fil
WO2018236145A1 (fr) Appareil et procédé de découverte de services de liaison montante et d'accès à ceux-ci dans un système de communication sans fil
WO2013073838A1 (fr) Procédé et dispositif de recherche de service pris en charge dans un réseau wi-fi direct
WO2016167618A9 (fr) Procédé et dispositif pour effectuer une découverte de service dans un système de communication sans fil
WO2019177231A1 (fr) Procédé de transfert d'informations sur un point d'accès cible dans un système lan sans fil et point d'accès l'utilisant
WO2014098437A1 (fr) Procédé et système de recherche de service dans un système lan sans fil
WO2018004106A1 (fr) Procédé, dispositif et support d'enregistrement lisible par ordinateur pour communiquer sur un réseau multi-groupe wi-fi en direct
WO2016148406A1 (fr) Procédé et dispositif pour prendre en charge un service par utilisation d'une plateforme de service d'application dans un système de communication sans fil
WO2016137224A1 (fr) Procédé et appareil pour transmettre des données dans un système de communication sans fil
WO2016148523A1 (fr) Procédé et dispositif pour exécuter une recherche de service dans un système de communication sans fil
WO2017018823A1 (fr) Procédé et dispositif permettant de former une session de plate-forme de service d'application dans un système de communication sans fil
WO2017014579A1 (fr) Procédé et appareil de réalisation de découverte dans un système de communication sans fil
WO2014030894A1 (fr) Procédé pour la configuration d'une liaison à grande vitesse dans un système wlan, et dispositif pour la mise en œuvre dudit procédé
WO2016111562A1 (fr) Procédé et appareil pour rapport d'état de batterie dans un wfd
WO2013122395A1 (fr) Procédé et appareil pour l'établissement d'une liaison à haut débit dans un système wlan
WO2017039376A1 (fr) Procédé et dispositif permettant l'échange d'informations de capacité de connexion dans un système de communication sans fil
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
WO2016209019A1 (fr) Procédé et appareil d'exécution d'une recherche à l'aide d'un mdns dans un système de communication sans fil
WO2018074871A1 (fr) Procédé de communication sans fil utilisant un vecteur d'attribution de réseau et terminal de communication sans fil correspondant
WO2022139488A1 (fr) Procédé et dispositif de resélection de terminal de relais dans un système de communication sans fil

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18915253

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

Country of ref document: EP

Kind code of ref document: A1