Admission Probe Mechanism for ICN Function Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Named Function Networking (NFN) over Information Centric Networks (ICN), significant communication bandwidth is wasted due to unnecessary data transfer of function parameters, especially when compute nodes are not capable of executing the requested function, leading to inefficient network performance, particularly in dense wireless networks.
Innovation Solution
A proactive admission control mechanism is implemented, where a service requestor node sends an admission probe interest packet with high-level function parameter specifications to determine the capability of potential NFN nodes, receiving a manifest with estimated execution times and resource requirements, allowing for selective data transfer only to capable nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If function parameters are transferred via interest packet to enable remote function execution, then the function can be executed remotely, but significant communication bandwidth is wasted when compute nodes cannot execute the function
Solution Approach 1:
The patent applies preliminary action by sending an admission probe interest packet before transferring actual function parameters. This probe packet contains high-level function parameter specifications that allow compute nodes to assess their capability to execute the function beforehand. Only after receiving a positive response (manifest packet confirming capability) does the requestor node transfer the actual input data, thereby avoiding wasted bandwidth on incapable nodes.
Solution Approach 2:
The patent introduces an intermediary mechanism - the admission probe interest packet and manifest data packet - that mediates between the requestor node and compute nodes. This intermediary layer enables capability assessment without requiring full parameter transfer, allowing the system to filter incapable nodes before actual data transmission occurs.
2Loss of energy
If all compute nodes are probed to determine execution capability, then unnecessary data transfer is avoided, but network overhead increases due to probe packets
Solution Approach 1:
The patent applies partial action by transferring only high-level function parameter specifications in the admission probe interest packet, rather than all detailed parameters. This partial transfer is sufficient for capability assessment but minimizes the overhead compared to transferring complete parameter sets. The mechanism balances the need for capability determination with minimizing probe packet size.
3Adaptability or versatility
If large data sets are transferred as function parameters, then the function can process comprehensive data, but network bandwidth consumption increases significantly
Solution Approach 1:
The patent uses preliminary action to send admission probe interest packets with high-level function parameter specifications before transferring large data sets. This allows the system to determine capability and filter incapable nodes beforehand, ensuring that only essential data is transferred to nodes that can actually process it, thereby reducing overall data transfer volume.
Solution Approach 2:
The patent extracts the capability assessment function from the main data transfer process. By separating the admission probe (with high-level specs) from the actual function parameter transfer, the system can evaluate suitability independently and avoid transferring large data sets to incapable nodes, thus reducing unnecessary data transfer volume.
Data Source
AI summary
Systems and techniques for efficient remote function execution in an information centric network (ICN) are described herein. For example, a requestor node may transmit an admission probe interest packet. Here, the admission probe interest packet includes a name that includes a function. The admission probe interest packet also includes a metric of a parameter of the function. In response, the requestor node may receive a manifest data packet. The manifest includes a metric of function execution at a node that created the manifest data packet. The manifest also includes a name of an implementation of the function. The requestor node may then determine that the metric of function execution meets a threshold and transmit an interest packet that includes the name of the implementation of the function.