WO2017173134A1 - Systèmes et procédés de création de groupes de multidiffusion dynamique dans un wi-fi pour des réseaux centrés sur les informations - Google Patents

Systèmes et procédés de création de groupes de multidiffusion dynamique dans un wi-fi pour des réseaux centrés sur les informations Download PDF

Info

Publication number
WO2017173134A1
WO2017173134A1 PCT/US2017/025125 US2017025125W WO2017173134A1 WO 2017173134 A1 WO2017173134 A1 WO 2017173134A1 US 2017025125 W US2017025125 W US 2017025125W WO 2017173134 A1 WO2017173134 A1 WO 2017173134A1
Authority
WO
WIPO (PCT)
Prior art keywords
client station
icn
cid
request
mac address
Prior art date
Application number
PCT/US2017/025125
Other languages
English (en)
Inventor
Alexander Reznik
Joseph S. Levy
Xiaofei Wang
Original Assignee
Interdigital Patent Holdings, Inc.
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 Interdigital Patent Holdings, Inc. filed Critical Interdigital Patent Holdings, Inc.
Publication of WO2017173134A1 publication Critical patent/WO2017173134A1/fr

Links

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
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • 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
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership

Definitions

  • IP Internet Protocol
  • ARP Address Resolution Protocol
  • a typical WiFi system includes an access point (AP) and a distribution system (DS) and in some cases a network controller.
  • AP access point
  • DS distribution system
  • the AP implements the 802.11 -specified physical layer (PHY) and Medium Access layer (MAC).
  • the DS contains a number of functions including: i) maintaining a registration of stations (STAs) and which AP they are currently associated with, maintaining local IP addresses for STAs, ii) interfacing between the MAC layer and the IP protocol; iii) maintaining AP and network configuration, and iv) supporting authentication protocols such as Extensible Authentication Protocol (EAP).
  • EAP Extensible Authentication Protocol
  • Examples of DS operations include determining certain management and configuration parameters and communicating these to the STAs using the MIB (management information base) and configuring ingress IP datagrams into 802.11 MAC SDU (service data unit) frames.
  • Multicast mode in which a single transmission by the AP is intended for multiple STAs is supported, but such support suffers from several limitations.
  • One such limitation is the means by which the "multicast group" is defined.
  • An 802.11 "multicast group" is simply the group of STAs which are designated to receive a particular multicast transmission.
  • a multicast MAC address is typically associated with a multicast group, and the AP addresses multicast frames to this group using the associated MAC address.
  • the STAs that are part of a multicast group are configured to receive transmissions associated with this MAC address in addition to their own MAC address.
  • a STA may be associated with any number of multicast groups and may therefore be configured to receive transmissions associated with any number of MAC addresses in addition to its own actual MAC address.
  • One aspect of multicast operation is the definition of multicast groups: the means by which the STAs are informed of which group(s) they are members and what the associated multicast MAC addresses are.
  • a typical WiFi implementation communicates this by broadcasting MIB variables.
  • Another approach is to use 802.11 MAC management frames. In both cases, it is the DS that makes the determination of which STAs should be part of which group, while the 802.11 MAC and PHY simply transport the information to the STAs.
  • ICN Information-Centric Networking
  • IP networking is built around a paradigm of a relatively stable host-to-host connection (from one specific IP address to another specific IP address).
  • the basic multicast mode in 802.11 involves simply the sending of group-addressed frames by the AP.
  • the AP is not aware of which STAs are part of the group, and it is assumed that the STAs are informed in some fashion of what group addresses they need to listen to, but how this is done is out of scope of the 802.11 standard. In practice, this is typically accomplished through the Management Information Base (MIB) settings.
  • MIB Management Information Base
  • the MIB is a framework for network management which involves either manual setting of parameters (through a user interface) or transmitting them to network devices using a network management protocol such as Simple Network Management Protocol (SNMP). From the perspective of 802.11, SNMP is just data payload in data frames.
  • SNMP Simple Network Management Protocol
  • MIB transmissions can be used to re-configure STAs, these are very slow, as there is no requirement for an STA to respond to a change in a MIB within any given time frame. In practice, many may only do so during a reset.
  • the basic multicast mode suffers from other issues, such as its poor reliability, and this resulted in several enhancements to this mode in 802.11.
  • the Directed Multicast Mode while critical for power-save modes, is designed to allow the STAs to request that multicast frames be sent to it using unicast mode with multicast MAC Protocol Data Units (MPDUs) embedded inside a unicast A-MPDU.
  • MPDUs Multicast MAC Protocol Data Units
  • the Flexible Multicast Mode was introduced to improve the power efficiency of multicast communications by allowing a STA using Power Save Multi-Poll (PSMP) to specify the rate at which the STA wishes to have multicast transmissions delivered to it.
  • PSMP Power Save Multi-Poll
  • FMS Flexible Multicast Service
  • a capability was introduced that allows the STA to issue a request to join a group (via the MAC layer management entity MLME-FMS. request primitive) without specifying the multicast address; the AP then allows (or refuses) the request via the MLME-FMS. response primitive, with the multicast address being specified in the response.
  • the MLME-FMS. request primitive uses the FMS-request information element which is the actual carrier of FMS-related information from the STA to the AP. That information element includes the TCLAS element which allows for various means of classifying traffic. In the case of an FMS request, the TCLAS element can be used by the STA to specify for the AP what type of multicast traffic it wants to receive, potentially specifying the multicast group address.
  • the AP responds to the STA by using the FMS-response element in the MLME-FMS. response. If a request to join (or "add") a particular multicast group is accepted, a group address is provided to the STA.
  • Disclosed herein are systems and methods for dynamic multicast group creation in WiFi for ICN environments. Some embodiment use FMS signaling in group creation. Additional embodiments include integration of object authentication/authorization techniques. Systems and methods described herein relate to content transmission, including management of a large number of group addresses and their association with named objects and STAs authorized to receive such objects.
  • Exemplary embodiments use the flexible multicast service (FMS) request and configuration procedures to perform one or more functions including: requesting/sub scribing to objects by binary IDs using FMS management frames; installing filters which can filter by object ID for delivery of object to the particular STA; associating a MAC Group ID and Object ID; and delivering the MAC Group ID to the STA.
  • FMS flexible multicast service
  • One embodiment takes the form of a method, comprising: receiving, from a first client station, a first Flexible Multicast Service (FMS) request that includes an information-centric network (ICN) content identifier (CID); responsive to the FMS request, generating a multicast group MAC address associated with the CID; retrieving content identified by the ICN CID from the ICN; and sending the retrieved content identified by the ICN CID to the requesting client station using the multicast group MAC address.
  • FMS Flexible Multicast Service
  • ICN information-centric network
  • Some embodiments support authorization and authentication of wireless stations.
  • the method further comprises receiving an authorization token from the client station, and forwarding the authorization token to an authorizing entity associated with the requested CID. Responsive to receiving a valid authorization response, the content is retrieved from the ICN. The content a separate encrypted unicast MPDU having the group MAC address and the content encryption key is sent to the first client, and the content retrieved from the ICN is encrypted with the content encryption key and provided to the client.
  • Some embodiments support assigning multiple client stations that are requesting the same content and both available to receive content during the same awake period to the same group MAC.
  • the method further comprises receiving, from the first client station, a first awake-time schedule, and assigning the first client station to a first target wake time group.
  • the retrieved content is transmitted to the first client during awake times of the first awake-time schedule. Additional client stations requesting the same content and are also available to receive content per the first awake-time schedule are added to the group MAC address.
  • FIG. 1A depicts an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. IB depicts an example wireless transmit/receive unit (WTRU) that may be used within the communications system of FIG. 1A.
  • WTRU wireless transmit/receive unit
  • FIG. 1C depicts an example radio access network (RAN) and an example core network that may be used within the communications system of FIG. 1 A.
  • RAN radio access network
  • FIG. ID depicts a second example RAN and a second example core network that may be used within the communications system of FIG. 1 A.
  • FIG. IE depicts a third example RAN and a third example core network that may be used within the communications system of FIG. 1 A.
  • FIG. IF depicts an exemplary network entity that may be used within the communication system of FIG. 1A.
  • FIG. 2 illustrates an exemplary TCLAS element structure.
  • FIG. 3 illustrates an exemplary TCLAS Frame Classifier Structure.
  • FIG. 4 is a table of TCLAS Frame Classifier types.
  • FIG. 5 is an illustration of a proposed Frame Classifier type for use in an ICN system.
  • FIG. 6 is an illustration of an exemplary TCLAS Frame Classifier Type 3 structure.
  • FIG. 7 is a flow diagram illustrating an exemplary FMS-based interaction between a PURSUIT-like ICN Client and Network Elements.
  • FIGs. 8A-8B are a flow diagram illustrating an exemplary FMS-based interaction between a CCN-like ICN Client and Network Elements.
  • FIG. 9 illustrates a method, in accordance with some embodiments.
  • FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, and the like, to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel -access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • the communications system 100 may include WTRUs 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a RAN 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • the communications systems 100 may also include a base station 114a and a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like.
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple- input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple- input multiple output
  • the base stations 114a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/1 16/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, and the like).
  • the air interface 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel-access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE- A LTE- Advanced
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, as examples, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, and the like) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, and the like
  • the base station 1 14b may have a direct connection to the Internet 110.
  • the base station 114b may notbe required to access the Internet 110 via the core network 106/107/109.
  • the RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and the like, and/or perform high-level security functions, such as user authentication.
  • the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the
  • RAN 103/104/105 or a different RAT.
  • RAN 103/104/105 or a different RAT.
  • RAN 103/104/105 or a different RAT.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and IP in the TCP/IP Internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. IB is a system diagram of an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • the transceiver 120 may be implemented as a component of decoder logic 119.
  • the transceiver 120 and decoder logic 119 can be implemented on a single LTE or LTE-A chip.
  • the decoder logic may include a processor operative to perform instructions stored in a non-transitory computer-readable medium. As an alternative, or in addition, the decoder logic may be implemented using custom and/or programmable digital logic circuitry.
  • the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (He B), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.
  • BTS transceiver station
  • AP access point
  • eNodeB evolved home node-B
  • He B home evolved node-B gateway
  • proxy nodes among others, may include some or all of the elements depicted in FIG. IB and described herein.
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115.
  • the RAN 103 may also be in communication with the core network 106.
  • the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115.
  • 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
  • the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node- Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected.
  • each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC mobile switching center
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • the RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface.
  • the MSC 146 may be connected to the MGW 144.
  • the MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.
  • the RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface.
  • the SGSN 148 may be connected to the GGSN 150.
  • the SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 106 may also be connected to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode Bs while remaining consistent with an embodiment.
  • the eNode Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio-resource-management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. ID may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management entity
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface.
  • the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the PDN gateway 166 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 107 may facilitate communications with other networks.
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.
  • the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (EVIS) server) that serves as an interface between the core network 107 and the PSTN 108.
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • EVIS IP multimedia subsystem
  • FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment.
  • the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
  • the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117.
  • the base stations 180a, 180b, 180c may implement MTMO technology.
  • the base station 180a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 180a, 180b, 180c may also provide mobility-management functions, such as handoff triggering, tunnel establishment, radio-resource management, traffic classification, quality-of- service (QoS) policy enforcement, and the like.
  • the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
  • the air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification.
  • each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109.
  • the logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point (not shown), which may be used for authentication, authorization, IP-host-configuration management, and/or mobility management.
  • the communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations.
  • the communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point.
  • the R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
  • the RAN 105 may be connected to the core network 109.
  • the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility-management capabilities, as examples.
  • the core network 109 may include a mobile-IP home agent (MTP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MTP-HA mobile-IP home agent
  • AAA authentication, authorization, accounting
  • the MTP-HA 184 may be responsible for IP-address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks.
  • the MTP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the AAA server 186 may be responsible for user authentication and for supporting user services.
  • the gateway 188 may facilitate interworking with other networks.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
  • the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point (not shown), which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs.
  • the communication link between the core network 109 and the other core networks may be defined as an R5 reference point (not shown), which may include protocols for facilitating interworking between home core networks and visited core networks.
  • FIG. IF depicts an example network entity 190 that may be used within the communication system 100 of FIG. 1A.
  • network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.
  • Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.
  • wireless communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers)
  • Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.
  • Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non- transitory data storage deemed suitable by those of skill in the relevant art could be used.
  • data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.
  • the network-entity functions described herein are carried out by a network entity having a structure similar to that of network entity 190 of FIG. IF. In some embodiments, one or more ' of such functions are carried out by a set of multiple network entities in combination, where each network entity has a structure similar to that of network entity 190 of FIG. IF.
  • network entity 190 is— or at least includes— one or more of (one or more entities in) RAN 103, (one or more entities in) RAN 104, (one or more entities in) RAN 105, (one or more entities in) core network 106, (one or more entities in) core network 107, (one or more entities in) core network 109, base station 114a, base station 114b, Node-B 140a, Node-B 140b, Node-B 140c, RNC 142a, RNC 142b, MGW 144, MSC 146, SGSN 148, GGSN 150, eNode B 160a, eNode B 160b, eNode B 160c, MME 162, serving gateway 164, PDN gateway 166, base station 180a, base station 180b, base station 180c, ASN gateway 182, MIP-HA 184, AAA 186, and gateway 188.
  • network entities and/or combinations of network entities could be used in various embodiments for carrying
  • a named object e.g. a piece of content
  • any client and thus any 802.11 STA
  • Mapping such transmissions to a unicast 802.11 MAC SDU is inefficient compared to using the 802.11 Multicast mode.
  • the 802.11 multicast mode one would generally associate a multicast group with each content name, which presents certain challenges.
  • the number of multicast groups defined may be very large because a single access point (AP) may be involved in a transmission of a very large number of named objects.
  • the groups may be defined for a very short time only (as long as the content is available).
  • the transmission associated with a group may follow the group definition in a very short amount of time, that is, the time between a configuration event and the reception of data may be very small.
  • STAs may need to be authorized to join a particular group.
  • An additional problem is that the 802.11 STA may not always be associated to the 802.11 AP when making a request. While in many cases a prior association is possible (which simplifies the operations that follow), in some case the overhead of an association is undesirable (e.g. if the STA is only interested in very infrequent content requests). Thus, enabling an STA to make requests without an association is beneficial.
  • STA is generally used to refer to an STA that is not an AP.
  • AP is used with the meaning set forth in 802.11 standards.
  • a reference to "setting a MAC address” herein refers to setting bits 2 through 47 of the 48-bit MAC address.
  • the setting of the VG and the U/L bits is discussed separately. More generally, it is understood that in the future, a longer address space may be used (more than 48 bits), but that such a future address space may still retain the I/G and U/L bits, although these do not have to be in the present positions.
  • "setting a MAC" address refers to setting all the bits except the I/G and U/L bits.
  • the "I/G bit” may be used to indicate whether a transmission is unicast (I setting, with I/G bit set to 0) or group/multicast (G setting with I/G bit set to 1). In an exemplary embodiment, group/multicast addresses are odd, while unicast addresses are even.
  • the U/L bit may be used to indicate whether the address is Universal (U setting with the bit set to 0) or Local (L setting, with the bit set to 1).
  • Universal addresses are determined to be globally unique. Local addresses are not and are to be used "within" a local network as needed. Multicast addresses are typically Local, although this is not necessarily the case for ICNs. Mapping Content Name to Group Address.
  • the identifier of a named information object in an ICN is mapped to a multicast group address.
  • a STA is expecting a named object with the name ⁇ CID>.
  • the STA may have subscribed to ⁇ CID> or may have directly requested it using some higher layer signaling.
  • the STA uses a predetermined function fAdd, which may be, for example, a Bloom Filter, to derive a group address (for example a 46 bits address) as follows:
  • the DS Upon receiving data with name ⁇ CID>, the DS performs the same operation and provides the data to the AP with the group address ⁇ grpAdd>.
  • the 802.11 system is not aware of whether a STA is authorized to access the content, nor does the 802.11 system have any means to restrict access. This can be addressed at higher layers, but doing so within the 802.11 system may have some benefits in terms of operational efficiencies and limiting the efficacy of denial of service (DoS) attacks.
  • DoS denial of service
  • FMS provides features that allow the STA to request a delivery traffic indication message (DTFM) and data rate higher than would otherwise be specified. This feature may be useful for a STA that subscribes to a named object. Moreover, the request/response structure of FMS setup and the fact that the request message does not need to specify a group MAC address lend themselves well to use in ICN-type communications.
  • DTFM delivery traffic indication message
  • FIG. 2 illustrates an exemplary TCLAS element structure.
  • FIG. 2 depicts the TCLAS element 200.
  • Embodiments disclosed herein address how a STA can specify the content in which it is interested as part of the FMS-request information element. This allows the STA to make requests without association. Such embodiments operate in cases where the AP is willing to entertain un-associated FMS requests.
  • the content of interest is specified via a TCLAS traffic classification element included in the FMS-request element.
  • the TCLAS element is generally used to specify a traffic filter/classification parameter to which the STA wants the requested FMS parameters to apply.
  • the structure of a TCLAS element is shown in FIG. 2.
  • the TCLAS element 200 includes an Element ID component, a Length component, a User Priority component, and a Frame Classifier component.
  • FIG. 3 illustrates an exemplary TCLAS Frame Classifier Structure, in accordance with some embodiments.
  • FIG. 3 depicts the TCLAS Frame Classifier component 300.
  • the Frame Classifier field includes the following subfields: Classifier Type, Classifier Mask, and Classifier Parameters.
  • the Classifier Type subfield is 1 octet in length and specifies the type of classifier parameters in this TCLAS.
  • the Classifier Mask subfield is 1 octet in length
  • FIG. 4 is a table of TCLAS Frame Classifier Types.
  • FIG. 4 depicts the table 400 that lists the Frame Classifier Types described in greater detail herein with respect to exemplary embodiments.
  • the Classifier Types are Type 3 types and the Reserved types. Embodiments using Reserved types may be implemented using techniques similar to the approach used in TCLAS Type 4 for IP. Namely, the specifics of the ICN frame header may be codified in the classifier structure to allow for filtering by those specifics.
  • ICN header has the following structure: CID (16 octets); ICN parameter 1 (2 octets); ICN parameter2 (2 octets), then this ICN-specific classifier might appear as in the example of FIG. 5.
  • FIG. 5 is an illustration of a proposed Frame Classifier Type for use in an ICN system.
  • FIG. 5 depicts the Frame Classifier Type structure 500 that includes a Classifier Type component, a Classifier Mask component, an ICN CID component, an ICN Parameter 1 component, an ICN Parameter 2 component, and a reserved component.
  • the embodiment of structure 500 of FIG. 5 is merely an exemplary embodiment; the exact ICN frame header format, and thus the structure of the ICN Classifier, may differ in different ICN implementations.
  • FIG. 6 is an illustration of an exemplary TCLAS Frame Classifier Type 3 structure, in accordance with some embodiments.
  • FIG. 6 depicts the structure 600 having a Classifier Type component, a Classifier Mask component, a Filter Offset component, a Filter Value component, and a Filter Mask component.
  • a Frame Classifier Type may be used to provide ICN support.
  • a Frame Classifier of Type 3 as depicted by the structure 600, may be used.
  • Use of the Type 3 classifier as described herein provides significant flexibility in how filtering is applied. Specifically, the Classifier Mask field is unused (reserved) at this time.
  • the Filter Offset indicated how many octets from the start of MPDU to apply Filter Value at.
  • the Filter Value and Filter Mask have the same meaning as for other classifier types - the Filter Value is a bit pattern to which the relevant section of MPDU (specified via the Filter Offset) is compared, while the Filter Mask indicated which of the bit positions are to be ignored (those are set to 0 in the Mask).
  • This structure allows significant flexibility in specifying filters based on ICN parameters. The implementation details may depend on the type of ICN naming that is adopted.
  • ICN architectures e.g. PURSUIT
  • PURSUIT make use of fixed-length bit-strings as IDs. See, e.g., D. Trossen, G. Parisis, Designing and Realizing an Information-Centric Internet, IEEE Communications Magazine Special Issue on "Information-centric Networking", July 2012. These IDs would be present in well-defined places in the ICN network packet header and thus in well- defined locations within the MPDU. This simplifies the process of defining masks, as the mask can match an ID.
  • an STA can set a TCLAS filter on the Scope ID (SID) rather than individual object ID (RID) which allows the STA to request that it be added to a multicast group for the whole scope.
  • SID Scope ID
  • RID individual object ID
  • FIG. 7 is a message flow diagram illustrating an exemplary interaction between an end device 708, including a PURSUIT-like ICN client and 802.11 STA 702 and the network elements of interest, such as the 802.11 AP 704 and the WiFi DS 706.
  • the steps performed in the interaction include the following.
  • the Client device 702 (which may be an 802.11 STA) initiates the process by issuing a request for content with ID ⁇ CID>.
  • This request can take the form of, for example, a subscription request or an interest/delivery request.
  • CID can refer to a specific object id (e.g. RID in PURSUIT) or a broader set of objects (e.g. SID in PURSUIT).
  • This operation is a network stack operation, in which the network stack is capable of supporting ICN operation (in addition or instead of traditional IP operations).
  • the request from the client device is provided to a Wi-Fi driver or adapter, which may be implemented as software that allows the network stack to interface with the STA (often a Wi- Fi network card).
  • the driver processes the request to create the Filter setting for a Type 3 TCLAS Classifier, or to create the ICN-specific TCLAS Classifier. Once the driver completes this, it passes the resulting classifier to the 802.11 MAC and causes the MAC to issue an MLME.FMS-request to add the STA to a multicast group.
  • the Wi-Fi driver may perform the following. The format of an ICN packet is determined, where CID will be in the header as well as the 802.11 MPDU that will carry this packet.
  • the STA constructs and transmits MLME.FMS-request.
  • the 802.11 AP 704 receives the MLME.FMS-request. In response to the request, the AP 704 may perform steps including the following. The AP 704 may process the request to "Add" the STA to a multicast group and (if it approves doing so) then the AP 704 transmits the group MAC address back to the STA (as shown). The group address is determined as follows. The AP may use an existing group address if all of the following conditions are satisfied: (1) Other STAs have already requested the content ⁇ CID>; (2) at least one of these requests is still valid (e.g.
  • the AP 704 determines that multicasting to the current STA will allow it to maintain the required QoS, DTFM, rate, etc. for this and other STAs. If these conditions are not satisfied, the AP 704 generates a new multicast address for the STA.
  • the AP 704 then forwards the following information to the WiFi DS system 706.
  • the AP 704 may forward information used to identify the FMS-request as an ICN request. This may be done in one of several ways. If the AP 704 is connected only to an ICN network that supports only a single type of ICN technology no information is required since all requests are assumed to be of the supported type of ICN technology. If the AP 704 is connected to multiple networks or to a network that can support multiple types of ICN technology (as well as potentially IP transmissions), then the DS identifies what type of a request this is. This can be accomplished in a number of different ways, including providing the AP 704 with the STA MAC address This can be implemented where previous signaling, e.g.
  • the TCLAS Classifier Mask (currently reserved) is used to signal the type of a request.
  • the AP 704 may further forward information used to identify ⁇ CID>. If Classifier Type 3 is used, this can be computed from the TCLAS Classifier Filter settings. For example, by combining the Filter Mask and Filter Value, the CID may be obtained. For an ICN-specific classifier, ⁇ CID> may be available directly in the classifier. The AP 704 may further forward the group MAC address associated with this FMS. request. [0103] In the embodiment of FIG. 7, the WiFi DS 706 stores the mapping between the ⁇ CID> and the group MAC address. This mapping is used later. When the WiFi DS 706 receives packets from the ICN network with ⁇ CID> content label, it uses this mapping to generate 802.11 MPDUs with the correct group MAC address.
  • the WiFi DS 706 may then re-generate the ICN request for ⁇ CID> (which was translated into MLME-FMS. request at the STA) and forward it to the network, e.g., to ICN node 708.
  • the ICN Request for CID may be forwarded by STA later in a regular data MPDU. This can be useful is the request may be used to carry data in addition to ⁇ CID>, such as metadata descriptors. In this case, the DS may skip this forwarding step.
  • This alternative approach may be used for content-centric networking (CCN) and other CCN-like ICN networks and is described in greater detail below with respect to FIGs. 8A-B.
  • the forwarding procedure for content received with ⁇ CID> is performed by operating the WiFi DS 806 to encapsulate the content in an MPDU with an associated group MAC address.
  • the output of this function is not necessarily restricted to 46 bits.
  • a longer output e.g. 128 bits (16 octets) or 256 bits (32 octets) is preferable to minimize collisions (different object names being assigned to the same string).
  • An additional complication is that the DS on the network side cannot determine the object name from the hash. There are two reasons for this. First, the hash is usually not one-to-one (again, the space of potential names in most applications is too large for any practical hash). Second, even if the hash were one-to-one, good cryptographic hashes are designed to make an inverse mapping computationally infeasible.
  • exemplary embodiments use a new management frame (or another MPDU) to forward the ICN request to the DS. This may be done instead of using the FMS request procedure.
  • the ICN request is translated into an MPDU (or a management frame) which is transmitted to the AP.
  • the AP extracts the ICN name from the request.
  • the AP may assign a group MAC address using a variety of methods and likewise communicate the group MAC address back to the STA using a new management frame or an MPDU.
  • the procedure may be implemented without requiring association. This approach, however, does not utilize the FMS procedure for multicasting and thus potentially sacrifices power efficiency and other advantages of the FMS procedure.
  • FIGs. 8A-B form a message flow diagram illustrating an embodiment that employs FMS procedure along with ICN request transmission in an MPDU. While FIGs. 8A-B illustrate the FMS procedure preceding the ICN request, the order of these steps may be switched. Similar to the flow diagram of FIG. 7, the flow diagram of FIGs. 8A-B illustrate an exemplary interaction between an end device 808, including a PURSUIT-like ICN client and 802.11 STA 802 and the network elements of interest, such as the 802.11 AP 804 and the WiFi DS 806. The steps performed in the interaction include the following.
  • the CCN name is hashed into a fixed length identifier ⁇ HTD>, which is used as the FMS mask. This is used for the forwarding of a CCN-like content delivery message from the ICN network, which is also more complicated than for a PURSUIT- like network.
  • the WiFi DS 806 does not simply encapsulate the received ICN message into an MPDU because the ICN header will contain the ⁇ name> string, but the filtering is set based on ⁇ HTD>. Thus, the DS first either changes the header or adds its own header containing ⁇ HTD> and only then creates an MPDU with the group MAC address.
  • the foregoing exemplary methods employs FMS mechanisms in 802.11 to improve reliability and power efficiency of ICN communications.
  • the techniques described below enable the network side (DS/AP) to verify that STA 802 is authorized to receive the content that it has requested.
  • a Client (STA) 802 could use a variation of the existing EAP/AAA based authentication before every ICN content request (e.g. before initiating an FMS-based procedure).
  • verification validation is performed by the "ICN" layer, so that the WiFi system delivers any content that an STA may request, and any STA can access any broadcast content transmission. If a client is not authorized to receive content that it received from the STA, it is incumbent on the ICN layer to make sure that the content cannot be accessed (e.g. by encrypting the content).
  • This approach suffers from the issue that the WiFi system (the STA and, potentially, the AP) may wind up processing frames that it does not need to process. This makes the system more susceptible to various forms of Denial of Service (DoS) attacks.
  • DoS Denial of Service
  • the Client device/STA 802 includes an access authorization token ⁇ TOK> in its FMS request.
  • the DS uses ⁇ TOK> to contact the content publisher/owner or another authorizing entity and confirm that the ⁇ TOK> represent a valid access request. If the WiFi DS 806 receives a confirmation, it proceeds with the procedure as in FIG. 7 or FIGs. 8A-B. If the WiFi DS 806 does not receive a confirmation, it rejects the request with an appropriate FMS-response.
  • the token ⁇ TOK> includes owner/publisher/verifier routing information. This information will allow the ICN network to properly route the token.
  • the token may further include an authorization signature, which may be a cryptographically derived value used by the client to prove that it is authorized to access the content. If the content name is not forwarded together with the ⁇ TOK>, then a name hash may be included as well so that the signature can be validated against the hash.
  • the use of ⁇ TOK> involves the use of an explicit transmission of ICN request using the CCN-based procedure in FIGs. 8A-B or a similar procedure.
  • the value of ⁇ TOK> may be included in the request.
  • the token procedure described above ensures that the Client/STA 802 that requested the content is authorized to receive it; however, the procedure does not prevent others from eavesdropping on the FMS exchange, mapping the ICN ⁇ name> or ⁇ CID> to the group MAC address and thus, potentially, receiving the content without authorization. To mitigate this, a further embodiment is described to enhance the security of communications.
  • the content authorizer upon successful confirmation of access request, provides the DS/AP a key ⁇ TKEY>.
  • the Client/STA can use its own content secret matter (which was used to derive ⁇ TOK>) to derive ⁇ TKEY>. Because each client STA shares a different key with the DS/AP, using these keys to encrypt and multicast content is not feasible. If the content is relatively short (or if the number of receivers is relatively small) it may be beneficial to simply switch in the unicast delivery mode of the encrypted payload (content) to each STA. However, when the content is large or when there are a large number of content receivers, a unicast approach can be very inefficient.
  • the DS/AP sends the Client/STA a unicast MPDU which contains one or both of the following encrypted (and signed) using ⁇ TKEY>.
  • the MPDU may contain the group MAC address. This allows the association of the address with content ⁇ name>/ ⁇ CID> to remain hidden.
  • the MPDU may contain the actual key matter used to encrypt data transmission, together with any information useful for the STA to properly synchronize to the key generator. This allows the AP to determine the encryption key for the multicast transmission in a manner which is STA independent and yet communicate it securely to all authorized STAs.
  • TWT Targeted Wake Time
  • 802.11 ah amendment for enabling sub- 1 -GHz communication
  • the procedure may be adapted to other 802.11 modes of operation.
  • the procedure is included both in specification framework document and the unofficial draft 0.1 of the 802.1 lax amendment.
  • the TWT procedure allows a requesting station (e.g. the client STA) to request setting of specific times when the requesting station should be awake (and thus when transmissions should be sent to that station).
  • the receiving station e.g. the AP
  • the procedure allows the responding station (e.g. the AP) to add the requesting STA to a TWT group for which the wake time parameters are identical and further to inform the STA of the TWT parameters for the group it has been added to.
  • TWT is integrated into the FMS-based procedures described above.
  • an STA sends a TWT request at substantially the same time that the FMS request is sent (as described with respect to FIG. 7 and FIGs. 8A-B).
  • the AP responds to the TWT request at substantially the same time that the FMS response is sent.
  • the request assigns the STA to a TWT group and provides all the relevant group parameters.
  • Both the "TWT request" and the "TWT response" may involve sending the same TWT setup Action frame, with request or response being indicated as part of the TWT information element carried by the frame.
  • 802.11 utilizes a contention based protocol, and FMS and TWT signaling is sent in different frames. Thus, it is technically not feasible to send them at precisely the same time, nor is it feasible to guarantee transmissions within a pre-defined time interval of each other. Thus, other techniques may be used to associate the FMS and TWT frames. In one embodiment, this is done by including an "expect TWT" flag as part of the FMS request procedure.
  • the TWT setup frame includes an 8-bit "Dialog Token" field. This field is filled with the CID/HID of the ICN request.
  • the AP In response to receipt of an FMS request with an "expect TWT" flag, the AP checks any incoming TWT setup requests for a match to the hash of the CID/HID. When such a request is found (within a pre-defined timeout time), the TWT request is associated with the FMS request. Since the Dialog Token is used by the STA and the AP to identify a TWT request/response exchange, it is preserved for the duration of the setup exchange, thus ensuring association going forward.
  • STAs may use Broadcast TWT to conduct ICN related transmissions
  • the AP may add the STA to one or more groups, such as a one or more multi-cast groups.
  • the AP may inform the STA of one or more multi-cast addresses, each associated with one or more CIDs.
  • the AP may include in its (short) beacons or other type of frames, a Broadcast TWT element.
  • the AP may indicate one or more TWT in the Broadcast TWT element; each TWT may be associated with one or more CIDs.
  • the STAs that are interested in one or more CIDs may be awake at the indicated TWT time.
  • the STA may send a frame to the AP indicating that it is awake and/or requesting the AP to send the data related to the CID(s).
  • the AP then sends content to the STAs during awake times associated with the TWT group.
  • FIG. 9 illustrates a method, in accordance with some embodiments.
  • FIG. 9 illustrates the method 900 that includes receiving a FMS request at 902, generating a group MAC address at 904, retrieving content from an ICN at 906, and sending the retrieved content to a requesting client using the group MAC address at 908.
  • an access point receives an FMS request having an ICN CID, such as the MLME-FMS. request sent from the STA to the AP in FIGs. 7 and 8 A, from a first client station.
  • an AP responsive to the FMS request, an AP generates a multicast group MAC address associated with the CID.
  • the MAC address may be generated as a function of the CID, such as using a Bloom filter to derive the MAC address.
  • the MAC address is based on a TCLAS element received in the FMS request.
  • the TCLAS element may be a Type 3 TCLAS classifier. This generated MAC address may be transmitted back to the first client station from which the FMS request was received.
  • the content identified by the ICN CID is retrieved from the ICN.
  • the retrieved content is sent to the requesting client station using the multicast group MAC address.
  • the method 900 may further include receiving, from a second client station, a second FMS request that includes the CID.
  • the second client station is then added to the multicast group having the generated MAC address for the first client station.
  • the second client also receives the content received from the ICN because it is assigned to the generated group MAC address.
  • a mapping between the MAC address and the CID is stored. The retrieved content is sent to the requesting client stations based on the stored mapping.
  • the FMS request further comprises an authorization token
  • the method 900 also includes before requesting the content identified by the ICN CID, forwarding, to an authorizing entity of the requested content, the authorization token. After receiving an authorization response, the content is retrieved from the ICN.
  • the method further includes sending, to the first client station, an encrypted unicast MPDU having the group MAC address and a content encryption key.
  • the first client station decrypts the requested content identified by the ICN CID with the received content encryption key.
  • the method 900 may further include receiving, from the first client station, a first awake-time schedule having awake-time parameters.
  • the first client is assigned to a first targeted wake time group per the first awake-time schedule, and the retrieved content is sent to the first client station during an awake time of the first awake-time schedule.
  • a second client station may also request, via an FMS request, the same CID as the first client station.
  • Information regarding the first awake-time schedule is sent to the second client station.
  • the second client station verifies it is able to receive transmission per the first awake-time schedule, or adjusts its awake-time periods to be available to receive transmissions per the first awake-time schedule, and confirms the awake-time schedule to the access point.
  • the second client station is added to the same group multi-cast address as the first client station.
  • the second client station may be added to a second group MAC address if it is not available to receive transmissions during the first awake-time schedule.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

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

Abstract

L'invention concerne des systèmes et des procédés pour la création de groupes de multidiffusion dynamique dans un Wi-Fi pour des environnements ICN. Certains modes de réalisation utilisent la signalisation FMS dans la création de groupes. Des modes de réalisation supplémentaires comprennent l'intégration de techniques d'authentification/d'autorisation d'objet. Les systèmes et les procédés décrits ici concernent la transmission de contenu, comprenant la gestion d'un grand nombre d'adresses de groupe et leur association à des objets nommés et des STA autorisés à recevoir de tels objets. Des modes de réalisation donnés à titre d'exemple utilisent une requête de service de multidiffusion flexible (FMS) et des procédures de configuration pour effectuer une ou plusieurs fonctions comprenant : la demande/l'abonnement à des objets, l'installation de filtres, l'association d'un identifiant de groupe MAC et d'un identifiant d'objet, et la distribution de l'identifiant de groupe MAC à la STA.
PCT/US2017/025125 2016-03-31 2017-03-30 Systèmes et procédés de création de groupes de multidiffusion dynamique dans un wi-fi pour des réseaux centrés sur les informations WO2017173134A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662316312P 2016-03-31 2016-03-31
US62/316,312 2016-03-31

Publications (1)

Publication Number Publication Date
WO2017173134A1 true WO2017173134A1 (fr) 2017-10-05

Family

ID=58549222

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/025125 WO2017173134A1 (fr) 2016-03-31 2017-03-30 Systèmes et procédés de création de groupes de multidiffusion dynamique dans un wi-fi pour des réseaux centrés sur les informations

Country Status (1)

Country Link
WO (1) WO2017173134A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019170069A1 (fr) * 2018-03-07 2019-09-12 Huawei Technologies Co., Ltd. Activation d'une multidiffusion dynamique orientée récepteur intercouche dans un accès cellulaire
CN113728606A (zh) * 2019-04-25 2021-11-30 交互数字专利控股公司 多播和单播介质接入控制(mac)地址指派协议(mumaap)
CN115175110A (zh) * 2022-06-23 2022-10-11 深圳市爱培科技术股份有限公司 一种基于组播的设备快速配网方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201212A1 (en) * 2011-09-08 2014-07-17 Emily H. Qi Methods and arrangements for device profiles in wireless networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201212A1 (en) * 2011-09-08 2014-07-17 Emily H. Qi Methods and arrangements for device profiles in wireless networks

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
D. TROSSEN; G. PARISIS: "Designing and Realizing an Information-Centric Internet, IEEE Communications Magazine Special Issue", INFORMATION-CENTRIC NETWORKING, July 2012 (2012-07-01)
DIRK KUTSCHER@NECLAB ET AL: "Multicast in Information-Centric Networking", 1 March 2012 (2012-03-01), XP055377448, Retrieved from the Internet <URL:www.ietf.org/proceedings/83/slides/slides-83-samrg-1> [retrieved on 20170531] *
EVGENY KHOROV ET AL: "A survey on IEEE 802.11ah: An enabling networking technology for smart cities", COMPUTER COMMUNICATIONS., vol. 58, 1 March 2015 (2015-03-01), NL, pages 53 - 69, XP055377560, ISSN: 0140-3664, DOI: 10.1016/j.comcom.2014.08.008 *
PENTIKOUSIS K ET AL: "Information-centric Networking: Evaluation and Security Considerations; draft-irtf-icnrg-evaluation-methodology-04.txt", INFORMATION-CENTRIC NETWORKING: EVALUATION AND SECURITY CONSIDERATIONS; DRAFT-IRTF-ICNRG-EVALUATION-METHODOLOGY-04.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERL, 11 March 2016 (2016-03-11), pages 1 - 34, XP015112049 *
V. JACOBSON: "Proceedings of the 5th international conference on Emerging networking experiments and technologies", 2009, ACM CONEXT, article "Networking named content"

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019170069A1 (fr) * 2018-03-07 2019-09-12 Huawei Technologies Co., Ltd. Activation d'une multidiffusion dynamique orientée récepteur intercouche dans un accès cellulaire
US20190281490A1 (en) * 2018-03-07 2019-09-12 Futurewei Technologies, Inc. Enabling Cross-layer Receiver Oriented Dynamic Multicast in Cellular Access
US10595222B2 (en) 2018-03-07 2020-03-17 Futurewei Technologies, Inc. Enabling cross-layer receiver oriented dynamic multicast in cellular access
CN113728606A (zh) * 2019-04-25 2021-11-30 交互数字专利控股公司 多播和单播介质接入控制(mac)地址指派协议(mumaap)
US11792154B2 (en) 2019-04-25 2023-10-17 Interdigital Patent Holdings Multicast and unicast medium access control (MAC) address assignment protocol (MUMAAP)
CN113728606B (zh) * 2019-04-25 2024-03-08 交互数字专利控股公司 用于多播和单播mac地址指派协议mumaap的方法和装置
CN115175110A (zh) * 2022-06-23 2022-10-11 深圳市爱培科技术股份有限公司 一种基于组播的设备快速配网方法及系统
CN115175110B (zh) * 2022-06-23 2023-11-03 深圳市爱培科技术股份有限公司 一种基于组播的设备快速配网方法及系统

Similar Documents

Publication Publication Date Title
US11877151B2 (en) Methods for service slice selection and separation
US10554553B2 (en) Anchoring IP devices in ICN networks
EP3556083B1 (fr) Système et méthode pour enregistrer des terminaux de service ip basés sur fqdn à des points de connexion réseau
EP2727295B1 (fr) Gestion de politiques de mobilité de données
TWI713614B (zh) 用於使用支援多個連線性和服務上下文的安全模型的無線通訊的方法和裝置
CN107646191B (zh) 用于在信息中心网络(icn)中锚定超文本传输协议(http)级服务的方法和系统
KR101614999B1 (ko) Ｍ2ｍ 디바이스에 대하여 다운링크 데이터에 대한 페이징을 수행하는 방법
KR20220139389A (ko) Quic와의 다중 호스트 다중경로 보안 전송을 가능하게 하기 위한 방법들 및 장치들
US20230061284A1 (en) Security and privacy support for direct wireless communications
WO2017173134A1 (fr) Systèmes et procédés de création de groupes de multidiffusion dynamique dans un wi-fi pour des réseaux centrés sur les informations
EP4275286A1 (fr) Changement d&#39;identifiants de liaison pc5 entre la wtru et le relais wrtu-wrtu de couche 2
WO2017201027A2 (fr) Perfectionnements de relais ieee 802.11ah

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17718196

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17718196

Country of ref document: EP

Kind code of ref document: A1