WO2016168116A1 - Procédé et appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur la base d'une mise en correspondance imparfaite - Google Patents

Procédé et appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur la base d'une mise en correspondance imparfaite Download PDF

Info

Publication number
WO2016168116A1
WO2016168116A1 PCT/US2016/026916 US2016026916W WO2016168116A1 WO 2016168116 A1 WO2016168116 A1 WO 2016168116A1 US 2016026916 W US2016026916 W US 2016026916W WO 2016168116 A1 WO2016168116 A1 WO 2016168116A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
publisher
cid
network
subscriber
Prior art date
Application number
PCT/US2016/026916
Other languages
English (en)
Inventor
Alexander Reznik
Dirk Trossen
Yevgeniy Dodis
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 WO2016168116A1 publication Critical patent/WO2016168116A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Definitions

  • This application relates to information centric networks and networking (ICN). More particularly, this application relates to the process of matching the publishers and subscribers of information into a communication relationship.
  • the Internet may be used to facilitate content distribution and retrieval.
  • IP Internet protocol
  • computing nodes are interconnected by establishing communications using IP addresses of these nodes.
  • ICNs routing functions are based on the content itself, rather than where the content is stored.
  • Content distribution and retrieval may be performed by ICNs based on names (i.e., Content Identifiers (CIDs)), of content, rather than IP addresses.
  • CIDs Content Identifiers
  • the content-based publisher and subscriber matching in ICNs is substantially indiscriminate in the sense that, if a subscriber requests a piece of content that is available from multiple sources (publishers), then the matching protocol chooses one of those publishers essentially randomly.
  • the invention pertains to methods, apparatus, systems, and techniques for matching information supply and demand in an Information Centric Network in which the matching is performed using contextual information, imprecise information, and/or imprecise matching.
  • contextual information about a piece of content such as its format, bitrate, or geolocation
  • the matching of a subscriber of content to a particular publisher of the requested content when there are several publishers that have the requested content may be based at least partially on selecting one of the publishers based on the closeness of contextual factors, such as desired data format, bitrate, and/or geolocation.
  • the subscriber to the information may request the content using only a partial identification of the requested content.
  • the technique may use an imperfect matching function, such as a fuzzy extractor, to match a content subscription with a content publication based on such imprecise information and/or imperfect matching criteria in a secure manner that preserves privacy and requires minimal signaling.
  • an imperfect matching function such as a fuzzy extractor
  • FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented
  • FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A; and,
  • WTRU wireless transmit/receive unit
  • FIGS. 1C-1E are system diagrams of an example radio access networks and example core networks that may be used within the communications system illustrated in FIG. 1A;
  • FIG. 2 is a block diagram of an exemplary fuzzy extractor
  • FIG. 3A is a block diagram of an exemplary network topology in accordance with one embodiment
  • FIG. 3B is a signal flow diagram in accordance with a first exemplary embodiment
  • FIG. 4 is a signal flow diagram in accordance with a second exemplary embodiment.
  • FIG. 5 is a diagram illustrating a namespace for ICN in accordance with an exemplary embodiment. DETAILED DESCRIPTION
  • FIG. 1A is a diagram of an example wireless 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, etc., 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 wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, 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.
  • 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, the Intemet 110, and/or the networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNodeB, a Home Node B, a Home eNodeB, 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 104, 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, etc.
  • BSC base station controller
  • RNC radio network controller
  • 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 cell 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, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 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 104 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 116 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 116 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. 1 A may be a wireless router, Home Node B, Home eNodeB, or access point, for example, 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, etc.) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, etc.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106.
  • the RAN 104 may be in communication with the core network 106, 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 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
  • the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106 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 the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired 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 104 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, non-removable memory 106, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • GPS global positioning system
  • 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 118 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 116.
  • 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, for example.
  • 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 MIMO 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 116.
  • 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, for example.
  • 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 106 and/or the removable memory 132.
  • the non-removable memory 106 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), etc.), 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 116 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.
  • 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
  • FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment.
  • the RAN 104 may employ a 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 106.
  • the RAN 104 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 116.
  • the Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104.
  • the RAN 104 may also include RNCs 142a, 142b. It will be appreciated that the RAN 104 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 RNC142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub 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. In addition, 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, macrodi versify, security functions, data encryption, and the like.
  • outer loop power control such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodi versify, 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 104 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 land-line communications devices.
  • the RNC 142a in the RAN 104 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 and 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 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 106 according to another 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 106.
  • the RAN 104 may include eNodeBs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment.
  • the eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNodeBs 160a, 160b, 160c may implement MIMO technology.
  • the eNodeB 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNodeBs 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 eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the core network 106 shown in FIG. ID may include a mobility management gateway (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 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.
  • MME mobility management gateway
  • PDN packet data network
  • the MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S I 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 eNodeBs 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 data planes during inter-eNodeB 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 106 may facilitate communications with other networks.
  • the core network 106 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 land-line communications devices.
  • the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. IE is a system diagram of the RAN 104 and the core network 106 according to another embodiment.
  • the RAN 104 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 116.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 106 may be defined as reference points.
  • the RAN 104 may include base stations 170a, 170b, 170c, and an ASN gateway 172, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 170a, 170b, 170c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the base stations 170a, 170b, 170c may implement MIMO technology.
  • the base station 170a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 170a, 170b, 170c 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 172 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like.
  • the air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 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 106.
  • the logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.
  • the communication link between each of the base stations 170a, 170b, 170c 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 170a, 170b, 170c and the ASN gateway 172 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, 100c.
  • the RAN 104 may be connected to the core network 106.
  • the communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.
  • the core network 106 may include a mobile IP home agent (MIP- HA) 174, an authentication, authorization, accounting (AAA) server 176, and a gateway 178. 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.
  • MIP- HA mobile IP home agent
  • AAA authentication, authorization, accounting
  • the MIP-HA 174 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 MIP-HA 174 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 176 may be responsible for user authentication and for supporting user services.
  • the gateway 178 may facilitate interworking with other networks.
  • the gateway 178 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 land-line communications devices.
  • the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • the RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks.
  • the communication link between the RAN 104 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104 and the other ASNs.
  • the communication link between the core network 106 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.
  • ICN information-centric networking
  • rendezvous procedure In approaches such as [1], [2] (all references are listed at the end of this specification), such rendezvous procedure generally performs a non-discriminative match, i.e., a single publisher is selected from a set of matching publishers offering the information while all subscribers (who have currently subscribed to the information) are chosen. In the case of several possible publishers, one publisher is randomly chosen. In [1], such procedure is performed offline and leads to the population of Forwarding Information Bases (FIB) routing tables in the intermediary forwarding elements, while [2] uses a centralized rendezvous function, which performs the matching procedure with every received publication and subscription.
  • FIB Forwarding Information Bases
  • [4] eliminate the need for real-time FIBs or determination of forwarding paths to subscribers by relying on a notion of "scope trees.”
  • [4] contains a per-scope centralized entity called a "scope root" which must match each content request with the ultimate location of each content item - among several potential locations.
  • discriminative steps into this procedure leading to a matching of publishers and subscribers based on one or more discriminative factors.
  • Such factors may depend on publisher and/or subscriber information as well as factors relating to the information itself.
  • information/content has some additional contextual information associated with its publication and the search operation provides close matches (possibly in a ranking manner), rather than exact matches.
  • This context information can take many forms - e.g., metadata.
  • the subscriber may provide some contextual information associated with its subscription request (or equivalent interest/delivery request for systems like [1] and [4]).
  • the ICN's Rendezvous function may match the contextual information in the
  • subscription/delivery request to the "closest" available publication context and map the subscription/delivery request to the corresponding publisher.
  • the request may be mapped to multiple publishers that are sufficiently close based on the matching criteria and allow the subscriber or another network node to make the final choice from the list.
  • a ranking result may be provided, where the "closest" matches are provided in a list, ranked according to a proximity metric.
  • the matching is done by a network function called the Rendezvous Point (RP) - which may or may not be centralized.
  • RP Rendezvous Point
  • the RP should be aware of context, which may be supplied by both publishers and subscribers/requestors. This introduces several issues. For instance, signalling and control overhead could be an issue. Specifically, context may (and often is) highly application dependent. Providing a full description for each publication and subscription may involve significant overhead.
  • context information may be sensitive. Disclosing certain context information to a third party - which an RP is in most cases - may pose significant security and privacy concerns.
  • Fuzzy extractors can be used in the content routing process to address at least some of these issues.
  • Some desirable characteristics for such a system include: (1) minimal signalling and control overhead over and above what already exists in an ICN system; (2) a low-complexity RP function implementation; and (3) security and privacy.
  • Fuzzy extractors can be implemented in ICNs using well-known techniques once the system requirements are well understood. [0069] This specification follows the conventions of cryptography literature and assumes binary (i.e., bit) strings for all quantities. It should be recognized that this leads to no loss of generality, as any countable (and indeed uncountable, but congruent to Reals) input distribution can be represented using binary strings. The use of binary strings is convenient both notationally (the notation is simpler) and practically. In particular, note that the output of the extractors can be readily used as binary cryptographic key matter.
  • a Fuzzy Extractor is constructed from two components, namely, and Extractor and a Secure Sketch. Each is briefly described below, including practical means for constructing them.
  • An extractor (or more precisely a randomness extractor) is a well-known tool in theoretical cryptography for "extracting randomness” from an input that contains inherent, but “imperfect”, randomness. More precisely, given an input drawn from a distribution X on ⁇ 0,1 ⁇ ', a randomness extractor produces a shorter output (hereinafter termed the
  • Randomness-extracted credential drawn from ⁇ 0, l ⁇ k , k ⁇ 1, (we use the notation ⁇ 0, 1 ⁇ ' for a binary string of length n bits and ⁇ 0, 1 ⁇ * for a binary string of arbitrary length) such that:
  • the output is statistically indistinguishable from that produced by uniform
  • the output of the extractor is statistically independent of the input up to a small factor ⁇ >0.
  • k is chosen to be less than the min-Entropy of X, where (1) the min-Entropy of X is a measure of the randomness present in X and (2) is defined as the minimum integer m such that for all x e ⁇ 0, 1 ⁇ ' , Prx(x) ⁇ 2 "m . It was shown (see [7] and also the books [8] and [9]) that randomness extraction can be achieved in theory, in particular using the well-known notion of universal hashing developed by Carter and Wegman [10], [11]. Moreover, [12] shows that commonly used hash functions such as SHA- 1, SHA-2, MD5, etc. can be utilized for the purposes of randomness extraction.
  • hash functions such as SHA- 1, SHA-2, MD5, etc.
  • the Sketch (SS) returns a string s e ⁇ 0,1 ⁇ *.
  • the Recovery procedure takes as inputs s and w', where w' is the other input to which we are attempting to determine a match with w.
  • d is an appropriate measure of "distance" on the input distribution, as will be discussed in more detail further below;
  • the security property of a Secure Sketch guarantees that, given s, the probability of guessing w is no better than 2 "m , where m is the min-entropy of the distribution from which w is drawn. In particular, if w is "perfectly random" - e.g., if w is an 1-bit string drawn uniformly from ⁇ 0,1 ⁇ ', then s leaks no information about w.
  • fuzzy extractors are constructed as follows. [0077] A Fuzzy Extractor is a pair of randomized procedures, Generate (GEN) and Reproduce (REP).
  • the Generate procedure takes an input string w and produces two outputs, namely, the extracted string R and a helper string P.
  • the Reproduce procedure takes as inputs a string w' and the helper string P.
  • FIG. 2 taken from [6], shows an exemplary construction of a Fuzzy Extractor. Particularly, it includes a GEN procedure 201 and a REP procedure 203.
  • GEN procedure 201 Ext 205 is a standard extractor (as described above) and SS 207 is a Secure Sketch as described above.
  • the REP procedure 203 includes a Rec procedure 209, which is a Recovery procedure for SS, as discussed above, and another extractor 211.
  • the value r is a random value used only on the GEN side to randomize the SS procedure. See [6] for details on how r is used.
  • the value x is a random quantity which gets included in P (and is therefore available to REP).
  • the value x may be included in any of a number of ways (e.g., added, multiplied, etc.) and may be used much like the variable r mentioned immediately above.
  • a fuzzy extractor is one example of an imperfect matching function that can be used to match subscribers and publishers in ICN (or, more generally, information requests with information responses in networks). Other imperfect matching functions may be used also. Examples of other imprecise matching functionality that can be used in other embodiments include linear correlation, information-theoretic functions such as conditional entropy, etc. 4 Use cases/Scenarios
  • Information Originator The entity which created or initiated distribution of the information/ content.
  • Publisher A network entity that makes the information/content available to subscribers (consumers), typically by either caching (for static content) or having the capability to produce the required information on demand. Note that, in many cases, the information originator also may be the publisher of the information/content.
  • Subscriber The consumer of content information.
  • RP Rendezvous Function
  • Context Additional information (e.g., metadata) associated with a particular piece of content.
  • the information originator may set some context associated with a piece of content.
  • a publisher may have some additional relevant context that may be added to the context from the originator in connection with the copy of the content that is resident at that publisher, e.g., geolocation or format (if the publisher changed the format of the content).
  • subscribers will have contextual information that may be set and incorporated into requests for content (e.g., geolocation, a particularly preferred format, etc.).
  • Examples of the context may include information related to: locations (geolocation, logical location, etc.) of the publishers and/or subscribers; identity information of the publisher and/or information originator; privacy requirements; price/cost of the information item(s); and quality of experience for the item (which may be data rate, resolution, etc.)
  • Content Identifier This is a value that uniquely identifies content/information. This value may be a plaintext name (as in, e.g., [1]) or a well-structured binary value designed to be easily machine processable (e.g. [2]). As with other details, the CID may take many forms, and what is important is that it can be used to uniquely name/identify content.
  • Context Signature A publically shared value that provides a cryptographically secure (i.e., it does not reveal the context) signature for a particular context. This value corresponds to the helper string P of a fuzzy extractor in embodiments that employ a fuzzy extractor for the imperfect matching functionality.
  • Context Validator A value shared with the network by the context signature generating entity. The value corresponds to the extracted string R of a fuzzy extractor.
  • an originator creates content with label CID that is made available to subscribers by a number of publishers.
  • Each publisher has a network context associated with it, denoted as CXT(PUBi) for publisher i.
  • the publisher's context may incorporate key information of importance to subscribers, for example, storage format, transcoding rate, network state, geolocation, logical location, etc.
  • Each publisher publishes CID to the RP function in the usual fashion, e.g., it makes the RP function (or, more generally, the network) aware that it is able to deliver the content named CID.
  • a "basic" procedure is considered in which a single subscriber chooses from among a number of publisher. This concept will later be extended to handle any number of subscribers - and how, in fact, this leads to potentially improved network operation.
  • FIG. 3A shows an exemplary network topology for this embodiment and FIG. 3B shows an exemplary signal flow diagram for these embodiments.
  • a subscriber 303 hereinafter "SUB”
  • the content 311 may be anything, e.g., a movie.
  • the context may be any one or more of a format (mpeg), a resolution (1080p), a geolocation of the subscriber node, a price that the subscriber is willing to pay for the movie, or any other information that might be used to select one copy of the content 311 bearing the particular CID for delivery to the subscriber as opposed to any other copy of content having the same CID.
  • It then uses a Fuzzy Extractor GEN function 309 to generate a pair (P,R) ⁇ GEN(CXT(SUB)).
  • P is the Context Signature
  • R is the Context Validator.
  • the subscriber 303, SUB forwards a Subscription Request 331 to RP 305 that includes the triplet (CID, P, R) through the network 301.
  • RP 305 sends subscription forwarding messages 333 that include the value P from the subscription request 331 to all publishers of CID 311, e.g., publishers 307i and 3073.
  • CID 311 e.g., publishers 307i and 3073.
  • the publishers have previously informed the RP 305 of the CIDs of the content that is available from these publishers.
  • Each such publisher 307i and 3073 uses the REP function 313 to produce a validation mask value Ri that is a function of P and that publishers contextual information, i.e.,
  • Ri -REP(CXT(PUBi),P) and include the resulting Ri in the communication 335 associated with the delivery of CID 311, e.g., it can be part of all associated packet headers.
  • RP 305 configures the network 301 to reject any delivery of content with Content Identifier CID 311 whose "validation mask" Ri does not match R.
  • FIG. 3B represents an exemplary embodiment in which the RP function 305 may be centralized (e.g., it may reside at a separate node on the network). This, of course, is merely exemplary (and, in fact, FIG. 3B is not necessarily preclusive of a distributed embodiment). In other embodiments, the RP function need not be centralized and may be distributed among the publishers and/or subscribers and other network elements. , Alternatively, no explicit RP functionality may exist. Instead, this functionality may be integrated into other network functionality, while the outcome of RP (i.e. matching publishers and subscribers) is nonetheless achieved. In order to simplify the discussion and not obfuscate the basic principles of the invention, FIG. 3B illustrates a single standalone, centralized RP 305. The procedure starts with several steps that are standard in ICN implementations (and will differ implementation by implementation). These are shown using gray arrows.
  • These steps include sharing of the CIDs (or CID exchange) 350.
  • the subscriber 303 needs to know the content identifier CID to which it wishes to subscribe. This CID is often learned by a subscriber as a result of information or protocols external to ICN (e.g., it is known by the application).
  • the content if not generated at the publishers 307, will need to be delivered from the content originator(s) 315 to the publishing nodes 307, as shown at 352.
  • the publishers 307 publish the CIDs of the content available from the publishers to the RP 305, as shown at 354. This also happens using standard means, which may differ from ICN implementation to ICN implementation. For example, in [1] (where RP function is implicit in FIB configuration), this is accomplished by properly configuring FIBs in the network nodes; and, in [2] and [4], this involves having each publisher send an explicit publication announcement to an actual RP node in [2] and scope root in [4].
  • next three steps are the ones outlined above, namely, (1) subscriptions sent from the subscriber node 303 to the RP 305, including the 3-tuple (CID, P, R) as previously described, as shown at 356 (2), the RP 305 sending delivery requests to publishers 307, including (CID, P), as shown at 358, and (3) the configuration of network nodes with (CID, R), as generally represented at 360.
  • the publishers 307 (potentially more than one) that have the requested content forward the content toward the subscriber 303 through the network 301.
  • the forwarding system may simply treat the pair ⁇ CID, R> as the content label/name/ID, but otherwise remain the same.
  • the system e.g., the appropriate forwarding node within network 301 "drops" the content simply because it does not know what to do with content ⁇ CID, Ri>.
  • each forwarding node can be configured with specific routing rules. This allows, for instance, the following options: i) forwarding the same CID to different destinations (different Ri values lead to different forwarding rules in a forwarding node); ii) forwarding to the same destination based on multiple potential context matches (same CID and different Ri values correspond to same forwarding rule).
  • Extractor's GEN function which creates outputs (P,R) that do not reveal the context or requested CID of the subscriber (except for an arbitrarily small leakage) to either the RP node 305 or the publisher node 307.
  • P,R outputs
  • the value P received from the subscriber 303 provides the publisher 307 even less information (up to an even smaller leakage value) about the subscriber's context, thus providing the subscriber additional privacy and protection against context leakage.
  • the RP knows the full (P, R) pair.
  • the publishers 307 know only P, while the routing nodes in the network 301 know only R.
  • Another application of the invention allows a subscriber to execute a search for content by name when it does not know the name precisely.
  • multiple CIDs are published into the ICN.
  • the subscriber knows an approximate content 10, ⁇ CID*>. It uses the GEN function to generate a context signature, P, and validator, R, from the partial context ID, i.e., ⁇ P, R> -GEN(CID*) and sends the pair ⁇ P, R> as a subscription to RP.
  • the RP forwards P to the publisher (or publishers) and configures the forwarding nodes to forward content marked with R to the subscriber.
  • the publisher(s) identifies candidate content, CIDi, i.e., content having a CID that matches CID*, and runs the fuzzy extractor REP function on it (using P as an input) to produce Ri - REP (CIDi, P). Then it forwards the content to the network, including Ri.
  • the RP does not receive any publications, and thus needs to consider all available publishing nodes (i.e., all potential storage location) as potential sources for the requested CID and, therefore, in at least some embodiments, must forward the requests to all publishers in its domain.
  • each publisher may produce and output a large amount of content, as the publishers do not have a CID from the subscriber. This may create a large load at the publishers and forwarding nodes (especially before all the mismatched data (i.e., the content for which Ri ⁇ R) is dropped by the network). Thus, this embodiment may not be practical in some networks, particularly larger networks.
  • One way to reduce the load in this type of embodiment is to include a "partial" CID with the signature P when the RP sends the delivery request message to the publisher. In this case, then the publisher would send publications only of content that matches the partial CID. With this modification, the procedure becomes almost exactly as in the embodiment of FIG. 3B, except that the CID is not necessarily a unique content name.
  • Exemplary options for CIDs in accordance with this concept include: a container descriptor (e.g., the "scope” in [4] or [2]) (in which case many different pieces of content share the same CID); an actual CID, with the unknown portion representing the originator context (this procedure then allows searching for the originator context); and a general category (e.g. video) within which the subscribers can search.
  • a container descriptor e.g., the "scope” in [4] or [2]
  • an actual CID with the unknown portion representing the originator context (this procedure then allows searching for the originator context)
  • a general category e.g. video
  • the context may be associated with an Information Originator that is a separate entity from the publisher.
  • the publisher may be just an in-network cache and may not be sufficiently trusted by the Information Originator with the contextual information. In such cases, it would be desirable to keep the context private from the publisher.
  • FIG. 4 is more representative of a distributed embodiment than FIG. 3B, wherein the RP functions can reside at the publishers, or be split between the publishers and the subscribers and/or other nodes. Note that, in this embodiment, the modifications tend to occur in the first, preparatory steps, rather than the later steps.
  • the Information Origin (or Origins) 415i, 4152, ... 415 n partitions the CIDs of its content into public and private portions, as shown at 450. Then it performs the GEN function of the fuzzy extractor on the private portions of the CIDs to generate a context signature Pi and a context validator Ri for each content, as shown at 452.
  • the information originators send the public portions of the CIDs along with the corresponding signatures Pi generated from the private portions of the same CIDs to the subscribers 403 through the network 401. This is done for every single public/private CID pair (or CID/Context pair, if context is used instead of private CID).
  • the information originators 415 send the publishers, such as publisher 407, the public CIDs of the content that the publishers store along with the validator Ri generated from the private portion of the same CID, as shown at 456.
  • the subscriber 403 When the subscriber wishes to subscribe to a piece of content, the subscriber 403 generates a Context Validator Qj using the fuzzy extractor's REP function for each Pj it was provided in step 454 using its own local CID search term (for search against a private CID) and/or context encoding (for content match), as shown at 460.
  • the subscriber 403 sends a message to the RP 405 subscribing to all content having the pair ⁇ public CID, Qj>, as shown at 462.
  • the publisher sends the requested content toward the subscriber and the forwarding network is configured as is usual in ICN, as shown at 466.
  • the RP function 405 may reside at the publisher.
  • (1) the signalling that was shown in FIG. 3B for sending delivery requests to the publisher (see 358 in FIG. 3B) is not shown here and (2) the forwarding of the content from the publisher 407, through the network 401, and to the subscriber 403 also is not separately illustrated, but is deemed to be subsumed within signalling 466.
  • Contextual information in ICN is likely to be encoded as metadata (e.g., XML documents, JSON objects, etc.).
  • metadata e.g., XML documents, JSON objects, etc.
  • secure sketches developed for other purposes, such as biometric authentication may not work well for metadata.
  • disclosed herein are Secure Sketches specifically optimized for metadata (and similarly structured objects). While the particular application of focus in this specification is ICN matching, the proposed Secure Sketches can be applied in any setting where a Secure Sketch for metadata-like objects is required.
  • the edit distance with moves disEditMove(w,w') is defined as the smallest number of insertions, deletions, and sub-string cut-and-paste operations needed to get from w to w', where a sub-string cut-and-paste involves removing a sub-string from the string and pasting it into a different position in the string.
  • This Secure Sketch for the edit distance is based on the shingling concept introduced in [15]. Particularly, consider a string w. Then, a c-shingle is a consecutive substring of w of length c. A c-shingling of w is the set of all c-shingles of w ignoring order in which the shingles occur or repetitions. For example, a 3-shingling of "abcdecdegh" is ⁇ abc, bed, cde, dec, ecd, deg, egh ⁇ . Note that cde appears only once, not twice.
  • the shingling approach converts an edit distance problem into a set difference problem, wherein a single insertion, deletion, or character change results in at most 2c- 1 differences in the c- shingling.
  • a single substring move results in at most 6c differences in the c-shingling (a substring move affects 3 adjacent character pairs), making that this approach is readily extendible to disEditMove.
  • This second construction is based on the erasure-code based technique for remote file synchronization as described in [17] .
  • a server which holds a string (equivalently a file) w that has changed a bit and it has a client which now holds a stale copy of it.
  • the "update" can be viewed as the secure sketch, the procedure of generating the update can be viewed as the SS function, and the procedure that the client uses to synchronize itself can be viewed as the REC function.
  • N is an integer greater than or equal to 1 and is a design parameter.
  • N should not be so large as to result in the need to "split" a single-character block, as this would not be possible.
  • N+l levels of string partitions where each level (n) contains 2nB blocks and each block at level n is contained within a single block at level n-1.
  • each block at each level is hashed using any secure hash, except that, at the very lowest level, the blocks are not hashed (e.g., the hash function is an identity function).
  • the hash is short. In particular, preferably, it is quite a bit shorter than the block size at the top level. On the other hand, preferably, it is large enough to reduce the probability of collision to a negligible value.
  • a block-alphabet (i.e. non-binary) erasure code is applied to the set of hashes for that level.
  • the code should be (i) systematic (meaning that the codeword contains the original input plus a set of check symbols) and (ii) designed to protect against at least 2k erasures, where k is the total number of edits and string moves needed to convert from the updated file to the outdated file.
  • Existence of such codes is well known (see, e.g., Fountain Codes (https://en.wikipedia.org/wiki/Fountain_code)).
  • the server starts at the top level and sends all hashes to the client.
  • the receiver (client) attempts to match the received hashes to all possible alignments in its copy of the file and reports to the server which hashes were matched and which were not.
  • the server goes down one level and sends the hashes for the sub-blocks of these (un-matched) hashes. This protocol continues until either all hashes are matched or the lowest level of blocks is reached. At that point, any still unmatched blocks are sent without hashes (recall we do not hash the lowest level), thereby allowing the receiver (client) to fill in any remaining "holes" in its file.
  • Each block has exactly two sub-blocks, with all blocks and sub-blocks as equally sized as possible.
  • the largest sub-blocks (first level) should have size (n/k) (to a nearest integer).
  • the smallest sub- blocks (lowest level) should have size log2(n) (to a nearest integer).
  • the acceptable collision (i.e., failure) probability is a design criterion. Generally, it can be kept very low even for rather short hashes.
  • d(v) is the number of children of v
  • v is called a leaf node (otherwise, v is called an internal node);
  • T(v) is the subtree starting at v, i.e., where v is the root of the sub-tree;
  • the tree is finite, i.e., the tree has a finite number of nodes (this also implies that it has a finite depth; however, the actual depth is not important to the present calculations).
  • a label l(v) is associated with each node v.
  • metadata typically is encoded using means that easily translate into a labelled tree. This may be illustrated with a simple XML-based metadata, taken from a W3C school tutorial on XML (http://www.w3schools.com/xml/xml_attributes.asp).
  • the XML document (a set of attributes associated with e-mail messages where the body of the exchange would have been the "data") is shown in FIG. 5 and the corresponding labeled tree is shown in FIG. 6.
  • DeleteLeaf (i ) operation can only be called for a leaf node v and results in removing v from the tree;
  • InsertLeaf ( ⁇ , ⁇ , ⁇ ) inserts a new child node for node v in position ; and label /, where we require d(v) ⁇ i-1 for the operation to make sense.
  • any labelled ordered tree can be converted into a string in such a way that: (1) the operation is 1-to-l, i.e., the original tree can always be recovered from the resulting string,(2) the three basic edit operations defined above (ChangeLabel, DeleteLeaf, InsertLeaf) correspond to a small well-defined number of basic string edit operations (insert/delete); and (3) the MoveSubTree operation corresponds to a small well-defined number of basic string edit operations (insert/delete) plus one sub-string move.
  • Conditions (1) and (2) can be satisfied by any of the well-known traversal algorithms for trees, the two most common being Depth First Search (DFS) and Breadth First Search (BFS).
  • DFS Depth First Search
  • BFS Breadth First Search
  • the tree labels are simply appended to each other in the order that the tree is searched.
  • Special characters may be used to mark boundaries between labels and to record special information that is dependent on the type of search.
  • this special information usually includes the node degree (i.e., the number of children that a node has), a marker that indicates the direction to the next node (up or down the tree), etc.
  • BFS this could be a node degree, a marker to indicate the last node in a level (which means that the traversal is moving one level down), etc.
  • Many textbooks on algorithms are available for more information on tree traversal, e.g., [17].
  • L be the maximum label size.
  • C be the number of digits in the maximum node degree.
  • ChangeLabel corresponds to a change of at most L characters and thus at most 2L string edit operations.
  • DeleteLeaf involves deleting one label (at most L characters), two special characters, and the node degree (at most 2 characters), and then changing the parent's node degree (at most 2 character edit). Thus, it corresponds to, at most, +8 string edit operations.
  • InsertLeaf is effectively the "mirror image" of DeleteLeaf, and also involves, at most, +8 string edit operations.
  • the algorithm for the Secure Sketch for the Tree Edit distance disTree may be described as: (1) use any appropriate tree-traversal algorithm (e.g., BFS or DFS) to convert the tree to a string and (2) apply an appropriate Edit Distance Secure Sketch to the string.
  • any appropriate tree-traversal algorithm e.g., BFS or DFS
  • sub-tree moves may be common (such that a Secure Sketch that can address dissubT is, in fact, needed).
  • DFS preserves sub-trees.
  • every sub-tree becomes a single contiguous sub-string of the overall string.
  • a sub-tree move becomes a sub-string move in a resulting string.
  • Embodiments such as those of FIGS. 2, 3A, and 3B provide solutions utilizing extra signalling between the RP and the publications and subscribers in addition to the 'pure' signalling of publications and subscriptions. Furthermore, the embodiment of FIG. 3B requires instructions to be sent to the forwarding subsystem to "drop" content forwarding if R does not match Ri. While these embodiments can be realized by amending existing systems such as [1][2] [4] to add such additional signalling, alternately, the following section outlines embodiments that embed the solutions within the basic signalling that is already defined in [1] [2] [3].
  • One embodiment uses a design for a namespace that the RP, publishers, and subscribers can use for communicating the fuzzy extractor information and wherein the final decision of the (fuzzy extractor) match is performed at the RP.
  • This embodiment is particularly suitable for ICN architectures such as described in [2] and [4].
  • FIG. 7 shows the proposed additional namespace, located under its own root identifier (/root) 710.
  • the next level places each publisher (PUBi) 712 and subscriber (SUBj) 714 as a scope identifier [2] under the root identifier.
  • SUBj 714 and PUBi 712 are used as examples for identifying a subscriber and publisher that has sent fuzzy extractor constraints to the RP, similarly to the embodiment of FIG. 3B.
  • Under each publisher 712 is located the content identifier CID 716 for which that publisher has indicated availability of the content, and, under each subscriber 714 is located the content identifier CID 717 for which a subscriber has shown interest.
  • each individual CID 716 and 717 is now located the fuzzy extractor information, e.g., calculated as described hereinabove.
  • the fuzzy extractor information e.g., calculated as described hereinabove.
  • P 718 and R 720 e.g., the context signature P and the context validator R, respectively, from the embodiment of FIG. 3B
  • Ri 724 e.g., the context signature P and the validation mask Ri, respectively, from the same embodiment
  • Each publisher PUBi subscribes to the fuzzy extractor information under /root/ PUBi /CID for each CID that it offers as content to the system.
  • the publisher PUBi Upon receiving, in response to that subscription, a publication of item P under any scope /root/ PUBi /CID (which exists in that location in accordance with the discussion in the following paragraph), the publisher PUBi will calculate the appropriate validation mask Ri for its copy of that content CID and publish that validation mask Ri back to the namespace under the same scope.
  • the RP subscribes to each SUBj and PUBi under the /root scope 710. Upon receiving, in response to each such subscription, a publication to a /CID under any SUBj 714 or PUBi 712, the RP will furthermore subscribe to the /root/ SUBj /CID scope or /root/ PUBi /CID scope, respectively, so that it receives any fuzzy extractor information pertaining to this CID.
  • the RP Upon receiving a publication in any /root/ SUBj /CID, the RP will subscribe to the items /root/ SUBj /CID/P and /root/ SUBj /CID/R to receive any fuzzy extractor constraints by the subscriber, e.g., P 718 and R 720.
  • the RP Upon receiving, in response thereto, publication under the items /root/ SUBj/CID/P and /root/ SUBj/CID/R, the RP will publish those received Ps under all /root/PUBi subscopes that contain content having the same CID (i.e., to all possible publishers of CID) and will subscribe to /root/PUBi/CID/Ri 724 in order to receive the validation mask Ri from publisher PUBi 716 (see next paragraph for description of the creation of Ri 724).
  • ICN architectures such as described in [1] do not perform a logically centralized rendezvous function. Instead, a periodic update of the so-called Forwarding Information Base (FIB) results in name-based forwarding tables that 'point' the node-local forwarding engine toward the next link along which the (published) information is likely to reside. Due to the periodic nature of the FIB updates (and its associated costs), it is unsuitable to consider the fuzzy extractor matching to be integrated into such a periodic update. Therefore, the additional signalling should be performed when making the local forwarding decision.
  • subscriptions are sent by clients by issuing an INTEREST packet which contains the CID of the content to be retrieved, while a DATA packet is returned from any matching publisher of this item CID.
  • the context signature P and the context validator R may be included as an XQUERY-compliant extension to the CID name, e.g.,
  • each CCN/NDN Content Centric Networking/Name Data Networking
  • each CCN/NDN Content Centric Networking/Name Data Networking router may perform the following operations:
  • the CCN router only forwards the INTEREST packet along the suitable link (which is associated with publisher PUBi) if R, as received in the INTEREST packet, matches Ri, as calculated in step 2 immediately above.
  • step 2 one can assume that the information regarding CXT(PUB) is part of the periodic update of the FIB state information, e.g., using some form of link state protocol.
  • a resolution service may be used that retrieves the context information CXT(PUB) for any publisher PUB (this resolution function might operate an additional CCN router local cache in order to minimize the need for on-demand resolution for every incoming INTEREST packet).
  • the CXT (SUB) is included in the interest packet and the (P,R) information for every Publishing node is appended to the CID entry in each FIB.
  • the functionality described hereinabove may be implemented in any reasonable manner, such as by software running on a processor, application specific integrated circuits (ASICs), logic circuits, analog circuitry, digital circuits, FPGAs, state machines, and/or any combinations of the above.
  • ASICs application specific integrated circuits
  • the functionality described hereinabove e.g., imperfect matching, fuzzy extractor GEN and REC functions, assembling and transmitting messages, receiving and extracting information from messages
  • That processor may interface with and at least partially control transmitter and receiver circuits to cause the described messages to be transmitted via networks (wired and/or wireless) or other means of electronic
  • the apparatus, methods, and functionality described hereinabove may be incorporated into one or more of the nodes described herein in connection with FIGS. 1A-1E and may use the processors, receivers, transmitters, transceivers, antennas, and other components of such devices along with the appropriate software to perform the methods and/or create the apparatus described herein.
  • 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 WRTU, UE, terminal, base station, RNC, or any host computer.
  • processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit (“CPU”) and memory.
  • CPU Central Processing Unit
  • memory may contain at least one Central Processing Unit ("CPU") and memory.
  • CPU Central Processing Unit
  • acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being “executed”, “computer executed”, or "CPU executed”.
  • an electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals.
  • the memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits.
  • the data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (“RAM”)) or non-volatile (“e.g., Read-Only Memory (“ROM”)) mass storage system readable by the CPU.
  • RAM Random Access Memory
  • ROM Read-Only Memory
  • the computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above- mentioned memories and that other platforms and memories may support the described methods.
  • Suitable processors include, by way of example, 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), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.
  • DSP digital signal processor
  • ASICs Application Specific Integrated Circuits
  • ASSPs Application Specific Standard Products
  • FPGAs Field Programmable Gate Arrays
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WRTU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer.
  • WRTU wireless transmit receive unit
  • UE user equipment
  • MME Mobility Management Entity
  • EPC Evolved Packet Core
  • the WRTU may be used m conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.
  • SDR Software Defined Radio
  • other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des procédés et un appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur lequel la mise en correspondance est effectuée à l'aide d'informations imprécises. La mise en correspondance peut être effectuée à l'aide d'un extracteur flou sur la base d'informations imprécises et/ou de critères de mise en correspondance imparfaits d'une manière sécurisée qui préserve le caractère privé et nécessite une signalisation minimale.
PCT/US2016/026916 2015-04-17 2016-04-11 Procédé et appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur la base d'une mise en correspondance imparfaite WO2016168116A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562149260P 2015-04-17 2015-04-17
US62/149,260 2015-04-17

Publications (1)

Publication Number Publication Date
WO2016168116A1 true WO2016168116A1 (fr) 2016-10-20

Family

ID=55910350

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/026916 WO2016168116A1 (fr) 2015-04-17 2016-04-11 Procédé et appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur la base d'une mise en correspondance imparfaite

Country Status (1)

Country Link
WO (1) WO2016168116A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019042110A1 (fr) * 2017-08-29 2019-03-07 华为技术有限公司 Procédé de publication d'abonnement, et serveur

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140310375A1 (en) * 2013-02-05 2014-10-16 Electronics And Telecommunications Research Institute Network node apparatus for information-centric networking and operating method of the network node apparatus

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140310375A1 (en) * 2013-02-05 2014-10-16 Electronics And Telecommunications Research Institute Network node apparatus for information-centric networking and operating method of the network node apparatus

Non-Patent Citations (18)

* Cited by examiner, † Cited by third party
Title
A. BRODER: "On the resemblance and containment of documents", PROC. OF COMPRESSION AND COMPLEXITY OF SEQUENCES, 1997
A. JUELS; M. SUDAN: "A fuzzy vault scheme", DESIGNS, CODES AND CRYPTOGRAPHY, vol. 38, no. 2, 2006, pages 237 - 257, XP019205891, DOI: doi:10.1007/s10623-005-6343-z
A. JUELS; M. WATTENBERG: "Proc. Sixth ACM Conf. on Computer and Comm. Security", November 1999, ACM, article "A fuzzy commitment scheme"
D. TROSSEN; G. BICZOK: "Not Paying the Truck Driver: Differentiated Pricing for the Future Internet", REARCH 2010 WORKSHOP IN CONJUNCTION WITH ACM CONEXT, December 2010 (2010-12-01)
D. TROSSEN; G. PARISIS: "Designing and Realizing An Information-Centric Internet", IEEE COMMUNICATIONS MAGAZINE SPECIAL ISSUE ON ''INFORMATION-CENTRIC NETWORKING, July 2012 (2012-07-01)
DODIS Y ET AL: "Fuzzy Extractors", 1 January 2008, SECURITY WITH NOISY DATA : ON PRIVATE BIOMETRICS, SECURE KEY STORAGE AND ANTI-COUNTERFEITING; [SECURITY WITH NOISY DATA], SPRINGER, GB, PAGE(S) 1 - 19, ISBN: 978-1-84628-983-5, XP007905702 *
J.. HASTAD: "Construction of a Pseudo-Random Generator from a One-Way Function", SIAM JOURNAL ON COMPUTING, vol. 28, no. 4, 1999, pages 1364 - 1396
L. CARTER; M. N. WEGMAN: "Universal Classes of Hash Functions", JCSS, vol. 18, no. 2, 1979, pages 143 - 154, XP000652858, DOI: doi:10.1016/0022-0000(79)90044-8
M. LUBY: "Princeton Computer Science", 1996, PRINCETON U. PRESS, article "Pseudorandomness and Cryptographic Applications"
M. N. WEGMAN; L. CARTER: "New Hash Functions and Their Use in Authentication and Set Equality", JCSS, vol. 22, no. 3, 1981, pages 265 - 279
O. GOLDREICH: "Foundation of Cryptography", 2001, CAMBRIDGE U. PRESS
R. OSTROVSKY; Y. RABANI: "Low-distortion embeddings for edit distance", PROC. OF 37TH ACM SYMPOSIUM ON THEORY OF COMPUTING, May 2005 (2005-05-01), pages 218 - 224
REN JING ET AL: "VICN: a versatile deployment framework for information-centric networks", IEEE NETWORK, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 28, no. 3, 1 May 2014 (2014-05-01), pages 26 - 34, XP011552208, ISSN: 0890-8044, [retrieved on 20140624], DOI: 10.1109/MNET.2014.6843229 *
T. H. CORMEN; C. E. LEISERSON; R. L. RIVEST; C. STEIN: "Introduction to Algorithms", 2001
U. IRMAK; S. MIHAYLOV; T. SUEL: "Improved single-round protocols for remote file synchronization", PROC. IEEE INFOCOM, 2005, pages 1665 - 1676, XP010829316, DOI: doi:10.1109/INFCOM.2005.1498448
V. JACOBSON: "Networking named content'', Proceedings of the 5th international conference on Emerging networking experiments and technologies", ACM CONEXT, 2009
Y. DODIS, SIAM JOURNAL ON COMPUTING, vol. 38, no. 1, 2008, pages 97 - 139
Y. DODIS: "Randomness Extraction and Key Derivation Using the CBC, Cascade and HMAC Modes", ADVANCES IN CRYPTOLOGY - CRYPTO, August 2004 (2004-08-01)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019042110A1 (fr) * 2017-08-29 2019-03-07 华为技术有限公司 Procédé de publication d'abonnement, et serveur

Similar Documents

Publication Publication Date Title
US11190446B2 (en) Anchoring IP devices in ICN networks
US9571463B2 (en) Policy-based access control in content networks
US9398461B2 (en) Handling information
US8943321B2 (en) User identity management for permitting interworking of a bootstrapping architecture and a shared identity service
US11206291B2 (en) Session control logic with internet protocol (IP)-based routing
CN109451804B (zh) cNAP以及由cNAP、sNAP执行的方法
US11363679B2 (en) Facilitating integrated management of connected assets in 5G and other advanced networks
WO2013003535A1 (fr) Négociation et sélection automatisées de protocoles d'authentification
EP3782393B1 (fr) Points d'extrémité d'authentification de réseau central 5g sur la base de service
US20230019089A1 (en) Communication system, method, and apparatus
US10924530B2 (en) Inter-provider file transfer system and method
CN108370322B (zh) 信息中心网络内的锚定因特网协议多播服务
US20150039761A1 (en) Content sharing within a private suer group
FI122163B (fi) Verkkopääsyautentikointi
EP2701447A1 (fr) Procédé permettant d'établir un réseau sans fil au moyen d'un identifiant de contenu
US20200145162A1 (en) Unified indexing framework for reference signals
WO2020251425A1 (fr) Nœuds de réseau et procédés qui y sont exécutés pour le traitement des fonctions de réseau
JP2016053950A (ja) Ｃｃｎパイプラインストリームの信頼性のあるコンテンツ交換システム及び方法
US20220174063A1 (en) Communication method, apparatus, and system
CN116633701B (zh) 信息传输方法、装置、计算机设备和存储介质
WO2016168116A1 (fr) Procédé et appareil de mise en correspondance de l'offre et de la demande d'informations sur un réseau centré sur l'information sur la base d'une mise en correspondance imparfaite
US11985497B2 (en) Systems and methods for network-based encryption of a user equipment identifier
US11991291B1 (en) Content-based domain name enconding, encryption, and routing system
US11956627B2 (en) Securing user equipment identifier for use external to communication network
WO2024032245A1 (fr) Procédé de communication et appareil de communication

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

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

Country of ref document: EP

Kind code of ref document: A1