KR20150015356A - Method and apparatus for delivering content from content store in content centric networking - Google Patents

Abstract

According to a device and a method provided by the present invention, at least one packet of interest comprising a plurality of requests from a node within a content centric networking (CCN) is received, availability of content is checked within a content store (CS) in response to a first request among the plurality of requests, and, when the content for the first request is available, available pieces of content for a set of sequential requests starting from the first request are extracted to be transferred to the node that has requested the content.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a method and apparatus for delivering content from a content store in a content-

The following embodiments relate to a method and apparatus for delivering content, and more particularly to a method and apparatus for delivering content from a content store (CS) within a content center network (CCN) .

Recently, a data packet network based on a Transmission Control Protocol (TCP) has been used in a computing environment. TCP is a fundamental protocol within the Internet architecture that manages the transmission of data packets within a data network. In a TCP-based data network, a user or a consumer of content may receive content by explicitly requesting content from an Internet Protocol (IP) address associated with a physical device or a location where a physical device is present . This limited addressing scheme may be inappropriate for fast growing network demand. In addition to TCP, there are also other protocols (e.g., User Datagram Protocol (UDP)) that also use IP-based addressing schemes.

Also for TCP based data packet networks, the request is sent by the consumer or user to receive the content. Such a request reaches the content server within the network, and the content server sends the requested content to the consumer. In a similar manner, a new request is sent by the consumer to the server to receive the requested content for all of the content. As an alternative to existing TCP (or UDP) based data packet networks, content-centric networking or a Content Centric Network (CCN) or Named Data Networking (NDN) has been developed.

In one aspect, there is provided a method comprising: receiving at least one packet of interest comprising a plurality of requests by a node in a content centric network (CCN); receiving a content store A sequential set of requests starting from the first one of the plurality of requests when the content for the first request is available, Wherein the available content for each request of the remaining ones of the sequential requests subsequent to the first request is one of the identified content for an immediately preceding request of each of the requests, And delivering the fetched available content, wherein the method comprises the steps < RTI ID = 0.0 > of: < / RTI >

The method further comprises transmitting the at least one interested packet to an adjacent node in the CCN to fetch the available content when the content for the first request is not available in the CS .

Wherein the method for delivering the content comprises modifying the at least one packet of interest prior to sending the at least one packet of interest to an adjacent node based on availability of content for the set of sequential requests within the CS .

Wherein modifying the at least one packet of interest may change at least one parameter of the at least one packet of interest by modifying at least one of a number of requests that the at least one packet of interest includes and a requesting start segment number.

Wherein fetching the available content comprises comparing the content for the first request with the fields of interest in the at least one packet of interest when the content for the first request is available in the CS, . ≪ / RTI >

The fields may include at least one of a prefix of the at least one packet of interest and a segment number of the content.

Wherein the step of delivering the fetched available content further comprises the step of transmitting content for the first request to a first node in the CCN requesting content for the first request when the content for the first request is matched to the fields And transmitting the data.

The information may indicate an index or pointer of the identified content for the immediately preceding request of each request

The step of fetching the available content may include the step of matching a prefix of each piece of candidate content with a prefix of the previously identified piece of content to identify the next piece of content identified previously .

The step of fetching the available content may comprise determining the content immediately following the previously identified content by comparing the segment number of each piece of content of the candidate content with the segment number of the previously identified content have.

The prefix of the previously identified content and the prefix of the content identified immediately after the previously identified content may be matched.

The difference between the segment number of the previously identified content and the segment number of the content immediately following it may be one.

In another aspect, there is provided a node for delivering content within a content center network (CCN), comprising: an integrated circuit including at least one processor; computer program code executed by the at least one processor; Wherein the at least one processor causes the node to perform a method when the computer program code is executed, the method comprising: receiving at least one packet of interest comprising a plurality of requests; Checking the availability of content in a content store (CS) for a first of the requests of the first request, when the content for the first request is available, from the first one of the plurality of requests Fetching available content for a sequential set of starting sequential requests, The available content for each request of the remaining ones of the sequential requests following the first request is fetched using information from the identified content for an immediately preceding request of each of the requests; And delivering the retrieved available content.

The node may be configured to transmit the at least one interested packet to an adjacent node in the CCN to fetch the available content when the content for the first request is not available in the CS.

The node may be configured to change the at least one packet of interest before sending the at least one packet of interest to an adjacent node based on availability of content for the set of sequential requests within the CS.

The node can be configured to change at least one parameter of the at least one packet of interest by modifying at least one of a number of requests included in the at least one packet of interest and a request starting segment number.

The node may be configured to match the content for the first request with the fields of interest in the at least one packet of interest when the content for the first request is available in the CS.

The fields may include at least one of a prefix of the at least one packet of interest and a segment number of the content.

When the content for the first request is matched to the fields, the content for the first request may be sent to a first node in the CCN that requested content for the first request.

The information may indicate an index or pointer of the identified content for the immediately preceding request of each request.

The node may be configured to match a prefix of each content of candidate content to a prefix of the previously identified content to identify the next content of the previously identified content.

The node may be configured to determine the content immediately following the previously identified content by comparing the segment number of each content of the candidate content with the segment number of the previously identified content.

The prefix of the previously identified content and the prefix of the content identified immediately after the previously identified content may be matched.

The difference between the segment number of the previously identified content and the segment number of the content immediately following it may be one.

Figure 1 shows a CCN according to one embodiment.
2 shows a block diagram of nodes in a CCN according to one embodiment.
FIG. 3 illustrates how content within a CS is stored according to one embodiment.
4A is a flow diagram illustrating a method for delivering content from a CS according to one embodiment.
FIG. 4B is a flowchart illustrating a method of extracting content for a first request according to an exemplary embodiment and a method of delivering content for a fetched first request.
4C is a flowchart illustrating a method of fetching content for sequential requests according to an example.
5 is a signal flow diagram illustrating a method for delivering content from a CS when a packet of interest according to an embodiment includes a plurality of requests.
6 is a flow diagram illustrating a method for delivering content from a CS when a packet of interest according to an example includes a plurality of requests.
FIGS. 7A and 7B illustrate exemplary implementation setups for illustrating the performance gain when using the method of delivering content from a CS according to an example.
8A and 8B illustrate exemplary implementation setups to illustrate performance gain when using the method of delivering content from a CS according to an example.
FIG. 9 shows a comparison of the time at which content delivery from the CS was performed for the scenarios described above with reference to FIG. 7, according to an example.
FIG. 10 shows a comparison of the time at which content delivery from the CS was performed for the scenarios described above with reference to FIG. 8, according to an example.
Figure 11 shows the average CS access time per attention for desktop machines according to an example.
Figure 12 shows average CS access time per interest for mobile devices according to an example.
13 illustrates a computing environment implementing a method for delivering content from a CS within a CCN according to an example.

In the following, embodiments will be described in detail with reference to the accompanying drawings. Like reference symbols in the drawings denote like elements.

The "node" referred to throughout this document may be a "node device ". For example, the terms "node" and the term "node device"

CCN is an alternative approach to the architecture of computer networks that provides new networking principles for efficient information sharing by using content names that can replace the host IP address (within the TCP / UDP network) or the complete TCP / IP network stack itself Lt; / RTI >

The CCN may provide a communication network that allows the user to focus on the data requested by the user rather than having a specific reference, the physical location at which the content is received. The CCN may also provide names based on routing, default caching of content, and per-packet security.

 Within the CCN, the request packet may be of interest (packet) and the response packet may be a content object. The content may be divided into chunks of appropriate size (i.e., content objects), and each interest (packet) may request a chunk. The node requesting the content may transmit a plurality of interested packets (each interested packet may be associated with a content object) in a sequential manner. In the CCN, for all interests (packets), a maximum of one content object may be received. In addition, the transmitted interest can be propagated to the content source by applying an appropriate name-based routing technique. Each intermediate node of the CCN that received the packet of interest may check the content object in its content cache (e.g., the content store CS). If the requested content object is found in the CS, then the node can respond with the content object, and if the requested content object is not found in the CS, the node will forward the forwarding information to the forwarding face (FIB) table entries, and then forward the packets of interest to the next node (e.g., an adjacent node) of the CCN. Before delivering the packet of interest, the intermediate node may store the intermediate packet information in its own attention table, known as the Pending Interest Table (PID). Delivery information can be populated manually or through appropriate routing techniques and stored in the FIB table. The node containing the content object may respond to the requestor by using a reverse path formed by the PIT entries generated at the intermediate nodes. If the interest is satisfied by the content, the PIT entry is removed from the intermediate nodes (including the end nodes) as the content passes through the adverse path.

The original CCN design may assume that up to one content object is expected to be received for one concern. Instead of using this inefficient way of transmitting one interest at a time, a plurality of requests can be aggregated to form a packet of interest. Packet packets of interest may not be sent for just one content object, but may be sent for a number of content objects and monitored by a dynamically changing entity known as the window size of the packet of interest.

First, when a packet of interest having a window size w-max (e.g., a predefined maximum value) is sent and the content sender receives it, the content sender can read the window size of the packet of interest and send the content to the requesting node . In addition, the interested packet information may also include a segment start range. The first missing content may be viewed as a point at which a new interesting packet has to be established and sent to the next node in the CCN. In this way, the window size of the packet of interest may be reduced (or remain unchanged) at each node based on content availability at each node.

The content in the CS may be organized in an orderly fashion for the changing segments (CCN chunks) for the same name component. When a packet of interest is received by a node, the corresponding content may be retrieved within the CS before the packet of interest is forwarded. In a typical CCN scenario, there may be a one-to-one mapping between the interest (packet) and the segment number of the content (e.g., indicating the content object).

If a packet of interest containing a plurality of requests is sent to obtain content, the packet of interest may request a group of contiguous content. For example, if a general method for accessing the CS is used when an interest is received, the packet of interest may need to be repeatedly re-established for the window size before checking the presence of the content via the CS. This is because the existing CS access mechanism does not support cases in which the interested packet requests more than one content. Also as a result of the above, the encoding and decoding of the packets of interest are repeatedly performed on the window-size.

Embodiments can achieve a method of delivering content from a content store (CS) by a node in the CCN. A node in the CCN may receive a packet of interest that includes a plurality of requests. In one embodiment, the node may be an electronic device such as a desktop computer, a laptop computer, a mobile phone, or other device connectable to a network. When the node receives the packet of interest, the node may be configured to check the availability of the content for the first request in the CS. If the content for the first request is available, the content for the first request may be verified by the node by matching the fields of interest, such as the prefix of the packet of interest and the segment number of the request . Once the content for the first request is verified, the node may be configured to send the content from the CS to the requesting node. For example, the first request may be the first request when the requests included in the packet of interest are sorted in a predetermined order.

The node may also be configured to fetch content for a set of sequential requests based on information of the identified content for the immediately preceding request. The information may indicate an index or pointer of the identified content for the previous request. The set of sequential requests may include all or some of the requests that the interested packet includes.

In one embodiment, the content for each of the requests following the first request may be identified using the next pointer to the identified content for the immediately preceding request of each request.

All requests in the packet of interest can be processed at the node using the following pointers or indices of the identified contents for previous requests.

Figure 1 shows a CCN according to one embodiment.

As shown, the CCN 100 may include a first node 101 and a plurality of second nodes 102, 103 and 104. The first node 101 may be configured to transmit a packet of interest containing a plurality of requests to a second node. The packets of interest may include parameters that may include an unlimited number of requests and a request start segment number.

In response to a packet of interest from the first node 101, the local CS (h = 0) or second nodes 102, 103 and 104 of the first node 101 are connected to the local CS Or the available content (s) associated with one or more requests based on the availability of the content at each of the second nodes 102, 103, and 104 to the first node 101. h may be a hop count.

In one embodiment, the packet of interest may be received at the local CS of the first node 101. The local CS (h = 0) may identify the content (s) associated with the requests in the packet of interest and then the local CS of the first node 101 may send the identified content (s) to the first node 101 ).

In one embodiment, the packet of interest may be transmitted to a neighboring second node within the CCN based on the availability of the content within the local CS of the first node 101. The packets of interest may be altered or modified prior to transmission to the adjacent second node of the CCN and the parameters in the packet of interest may be changed or modified based on the availability of the content associated with one or more requests in the packet of interest.

2 shows a block diagram of nodes in a CCN according to one embodiment.

As shown, the first node and the second node of the CCN are located in a state in which a plurality of applications of applications 1 through n are present in a node (first node 101 or second node 102, 103 and 104, respectively) Application layer. In one embodiment, the application may be a browser installed on the first node.

A node of a CCN may include libraries that may include, but are not limited to, sensors, media framework, and CCN library, and the like.

The node may include a CCN engine 200. The CCN engine 200 may include a CS 200a, a PIT 200b, and a FIB 200c. The node requesting content (the first node 101) sends a packet of interest containing one or more requests (each corresponding to a content object). By applying an appropriate name-based routing scheme, the transmitted attention (packet) is propagated to the CS. Each intermediate node that receives the packet of interest may check the content object in its content cache (e.g., CS). If the requested content object is found in the CS 200a, the node may respond with the content object; otherwise, the node may forward the packet of interest to the next node. Before forwarding a packet of interest, the node may store the packet information of interest in an interest table, e.g., known as PID 200b. The delivery information may be manually or implanted through appropriate routing techniques and stored within the FIB 200c.

In addition, the CCN engine 200 may transmit a packet of interest to a network layer through a transport layer, as shown in FIG.

The technical contents described above with reference to FIG. 1 can be applied as it is, so a detailed description will be omitted below.

FIG. 3 illustrates how content within a CS is stored according to one embodiment.

The content in CS 200a may be organized in a sequential manner as shown. For example, the content may be stored in CS 200a in a sequential manner from content 0 to content N. [ It is also shown that a packet of interest 300 containing a plurality of requests can include requests 0 through N and be received at the CS 200a. When CS 200a receives the packet of interest, CS 200a may check the availability of content 0 for request 0 in the packet of interest. If content 0 is available, then other requests (Request 1 to Request N) may be processed in CS 200a based on the information of identified content 0. In one embodiment, the information in the content may represent an index or pointer to the identified content for the immediately preceding request. The identified content may be fetched (e.g., from CS).

The technical contents described with reference to FIG. 1 and FIG. 2 may be applied as they are, so a detailed description will be omitted below.

4A is a flow diagram illustrating a method for delivering content from a CS according to one embodiment.

As shown in FIG. 4A, at step 401, a node of the CCN may be configured to receive a packet of interest that includes a plurality of requests. When the node receives the packet of interest, in step 402, the node of the CCN may be configured to check the availability of the content corresponding to the first of the plurality of requests in the packet of interest within the CS (belonging to the node) .

In step 402, the node may determine whether the content for the first request is available within the CS. If the node determines that the content for the first request is available, then in step 403, the node may be configured to fetch the available content for the set of sequential requests starting from the first request (step < RTI ID = 0.0 > E.g., from the CS in which the content (s) are present). Step 403 may include steps 404-1 through 404-4 described below.

At step 404-1, the node may determine whether the content (s) for the remaining request (s), except the first of the sequential requests originating from the first request, are available within the CS.

At step 404-2, if the content (s) for the remaining request (s) are available in the CS, the node may retrieve the content (s) for the remaining request (s).

At step 404-3, if at least one of the content (s) for the remaining request (s) is not available in the CS, the node may modify the received at least one packet of interest. At step 404-4, the node may send (or forward) the changed at least one interested packet to an adjacent node. For example, a node may send at least one interesting packet (or packet) to a neighboring node before transmitting (or forwarding) the received at least one interested packet to an adjacent node based on the availability of content for a set of sequential requests starting from a first request in the CS Can be changed. The node may change at least one parameter of the at least one packet of interest by changing at least one of the number of requests included in the at least one packet of interest and the request starting segment number.

Steps similar to steps 402 and 403 described above and steps 405 through 407 described above may be performed by an adjacent node that received the modified attention packet and steps of sequential requests beginning with the first request may be performed The content (s) for the remainder of the request (s) can be identified and retrieved.

In step 405, the node may be configured to deliver the available content within the CS. For example, the node may deliver fetched content (s). Unlike what is shown, a node may deliver content for each request to the requesting node whenever content for each request is identified and retrieved.

If the node determines in step 402 that the content for the first request is not available in the CS, then in step 406 the node sends (or forwards) the packet of interest to a neighboring node in the CCN Lt; / RTI > For example, the node may send at least one interested packet to an adjacent node in the CCN to fetch the available content for requests when the content for the first request is not available in the CS.

In step 407, a step similar to steps 402-406 described above by an adjacent node that received the packet of interest may be performed and a plurality of requests included in the packet of interest, or a sequential Lt; / RTI > can be identified and retrieved.

The identified and retrieved content may be delivered to the requesting node.

In step 403 described above, the node may use the information from the pre-identified content for the immediately preceding request of each request to identify and fetch the content for each request. For example, the available content for each request of the remaining ones of the sequential requests following the first request may be fetched using information from the identified content for an immediately preceding request of each request .

The flow chart of FIG. 4A can be illustrated with the following examples.

In one example, it can be considered that a packet of interest containing 10 requests (Request 0 to Request 9) is received by the node. First, the node may determine whether the content for the first request (e.g., request 0) is available within the CS (belonging to the node). If the content for the first request (request 0) is not available within the CS belonging to the node, then the node may forward the packet of interest to the neighboring node of the CCN. For example, an adjacent node may be the second node of the CCN.

If the content for the first request is available in the CS (belonging to the node), then the node can then process the set of sequential requests in the packet of interest starting from the first request. The CS belonging to the node may send the identified content for the first request to the node and may begin processing the remaining sequential requests after the first request has been processed.

In one embodiment, request 1 (request following request 0) may be processed using information of the identified content for the first request (request 0). Since the content in the CS is assumed to be stored in a sequential manner, the CS may detect (or identify) the content 1 for the request 1 by using the information in the content 0 identified by the request 0. [ The information of the content may include, for example, indexes available in each content in the CS.

In one embodiment, the CS may process request 1 to identify content 1 using the index or the next pointer to the identified content 0 for request 0. When the content 1 is available using the information of the content 0, the CS can transmit the content 1 from the CCN to the requesting node.

In a similar manner, a CS (belonging to a node) can process a third request (e.g., request 2) using information in the immediately preceding content (e.g., content 1). If the CS belonging to the node identifies content 2 for request 2, then the CS can send the content 2 to the node.

If it is determined that the content 2 is not available in the CS, then the node containing the CS may modify or modify the packet of interest and send the packet of interest to the neighboring node of the CCN.

Thus, as described above, the content within the CS can be identified based on the information of the immediately prior identified content available in the CS. When specific content for the request is not available, the node may be configured to modify the packet of interest, and the node may send a packet of interest to an adjacent node of the CCN to obtain content (s) for multiple requests in the packet of interest Lt; / RTI >

In one embodiment, the packet of interest may be altered or modified by changing the parameters of the packet of interest. For example, if only content 0 and content 1 are available in the CS belonging to the node, the packet of interest may be altered or modified and sent to an adjacent node.

For example, the number of requests in a packet of interest may be changed to nine and the request start segment number may be changed to two. The modified or modified attention packet may be sent to the neighboring node by the node (initial node) requesting the content from the CCN.

Further, an adjacent node may receive a packet of interest configured to identify content for a first request (e.g., the first request originating from request 2). Adjacent nodes may be configured to identify content for request 2 by retrieving the CS (belonging to the adjacent node). If the content for request 2 is identified in the CS, the next neighboring node can be configured to handle the next request (request 3) based on the information in the available content (e.g., content 2) corresponding to request 2 have.

Request 3 may be processed in a CS (belonging to an adjacent node) using information of the identified content (e.g., content for request 2).

Thus, using the above method, the content in the CS can be easily processed and the CS access time can be optimized. The steps shown in FIG. 4A may be performed in the order shown or in a different order, or may be executed simultaneously. Also, in some embodiments, some of the steps shown in FIG. 4A may be omitted.

FIG. 4B is a flowchart illustrating a method of extracting content for a first request according to an exemplary embodiment and a method of delivering content for a fetched first request.

The above-described step 403 may include the steps 404-5 and 404-6 described below, and the above-described step 405 may include step 408. [

At step 404-5, the node is configured to match the content for the first request with the fields of interest in the received at least one interest packet when the content for the first request in the CS is available . The fields of interest in the received at least one interesting packet may comprise at least one of a prefix of the packet of interest and a segment number of the content.

At step 404-6, the node may fetch the content for the first request if the content for the first request matches the fields of interest in the received at least one care packet.

In step 408, when the content for the first request matches the fields of interest in the received at least one interest packet, the node sends the content for the first request to the first node in the CCN requesting the content for the first request, Lt; / RTI > For example, the node may send content for the fetched first request to the first node in the CCN that requested the content for the first request.

4C is a flowchart illustrating a method of fetching content for sequential requests according to an example.

The above-described step 403 may include the steps 404-7 and 404-8 described below.

At step 404-7, the node may match the prefix of each content of candidate content with the prefix of the immediately previously identified content, to identify the next content of previously identified content. Each of the candidate content may correspond to each piece of content in the CS.

In step 407-8, the node may determine the content that is identified immediately after the previously identified content by comparing the segment number of each content of the candidate content with the segment number of the previously identified content. The candidate content in step 407-8 may be content whose prefixes match each other by performing step 404-7.

For example, the prefix of the previously identified content and the prefix of the content identified immediately after the previously identified content can be matched, and the segment number of the previously identified content and the segment number of the previously identified < RTI ID = 0.0 > The difference between the segment numbers of the identified content may be one.

The technical contents described with reference to Figs. 1 to 3 can be applied as it is, and a detailed description will be omitted below.

5 is a signal flow diagram illustrating a method for delivering content from a CS when a packet of interest according to an embodiment includes a plurality of requests.

5 shows a first node 101 and a plurality of second nodes 102 and 103, respectively. For example, the number of requests in FIG. 5 may be considered as 10. However, more than ten or fewer requests may be included in the interest packet for obtaining content from the CCN.

5, first, the first node 101 sends a packet of interest (actual interest) having a request size W _c of 10 to a local CS (h = 0).

In one embodiment, the application in the first node 101 may be configured to send the packets of interest to the local CS (h = 0). For example, the application may be a browser.

As shown, the local CS (h = 0) may receive the packet of interest 301 from the first node 101. In addition, the local CS may process packets of interest to identify the content associated with one or more requests. Local CS can check whether the content is available on a first request C _0. If the content C ₀ is available, the local CS can parse the content C ₀ . In addition, the local CS may verify the content for the first request by matching the content with, for example, prefixes and fields of interest such as the segment number of the content. Local CS may identify that the content C ₀ match the field of interest, followed by a local CS may transfer the content C ₀ of a first node 101.

As shown in FIG. 5, the local CS (h = 0) may send content (e.g., content C ₀ ) for request 0 in response to the actual interest packet received from the first node 101.

In one embodiment, the local CS (h = 0) can fetch the content (content C ₁ ) for the second request (e.g., request 1) using the information of content 0 (content C ₀ ) have.

The information may indicate the next index or pointer of content zero.

Since the content is stored in a sequential manner as shown in Figure 3, the content for request 1 can be easily retrieved using the next pointer or index of identified content 0 (content C ₀ ). Since the content (content C ₁ ) is encoded and stored in the local CS belonging to the first node 101 when the local CS (h = 0) fetches the content for the request 1, the local CS stores the content (content C ₁ ) can be analyzed. In addition, the local CS may be configured to match the content (content C ₁ ) to the prefix of the previous content (e.g., content C ₀ ). If the prefix of the content C ₁ matches the prefix of the content C _0, it is determined for the content C ₁ is identified whether or not the next content of the content C ₀ can be carried out in the following.

If the prefix of the content C ₁ does not match the prefix of the content C ₀ , then the packet of interest may be modified or modified and sent to an adjacent node (e.g., the second node 102).

In one embodiment, the determination may be performed by comparing the segment number of the content C _{1 with} the segment number of the content C ₀ .

Content C ₁ is to determine whether the next content of the content C _0, the difference between the segment number and the content C ₀ of the segment number of the content C ₁ may be one.

If the determination is true (e.g., content C ₁ indicates the next content of content C ₀ ), then verification may be performed by matching the content (content C ₁ ) to the remaining fields of interest . When the remaining fields of interest are matched, the content C ₁ may be transmitted from the local CS (h = 0) to the first node 101.

In one embodiment, content C ₀ and content C ₁ associated with request 0 and request 1, respectively, may be received at the first node 101 after processing time (PT) at the local CS (h = 1) . In a similar manner, each piece of content associated with each request in the packet of interest may be received at the first node 101 after the PT at each of the second nodes 102 and 103 where the content is available. The PT may indicate the time taken by the CS to process each request in the packet of interest.

In addition, the local CS (h = 0) may begin to identify the content for request 2 using the information of the previous content available (e.g., content C ₁ ). If the content for request 2 is not available at the local CS (h = 0), the first node 101 may be configured to modify the actual packet 301 of interest.

The local CS (h = 0) may change or modify the actual interest packet 301 and may transmit the modified or modified interest packet to the adjacent second node 102. The hop count of the second node 102 may be one (h = 1).

In one embodiment, the first node 101 may be configured to change the number of requests in the packet of interest 301, and may provide the requested start segment number to the modified packet of interest. As shown, the modified or modified attention packet 301a may contain a window size of 8 (the number of requests in the packet of interest) and may have a starting segment number of two.

When the second node 102 (e.g., a node adjacent to the first node 101) receives the modified or modified attention packet 301a, the second node 102 sends a request 2 And to process the modified attention packet 301a to identify the content associated with request 9, as described above.

The second node 102 may be configured to determine the availability of content for a third request (e.g., request 2) since the request start segment number in the modified attention packet 301a is two. When the second node 102 determines the content for request 2, the second node 102 sends the content for request 2 to the CCN engine (belonging to the local CS (h = 0)) of the first node 101 Lt; / RTI > In addition, the local CS (h = 0) may store the content (content C ₂ ) for request 2 and send the content for request 2 to the first node 101.

The second node 102 may be configured to identify the content (e.g., content C ₃ ) for request 3 using the information in the immediately preceding content (content C ₂ ) that was identified.

In one embodiment, the second node 102 may be configured to identify the content (content C ₃ ) using the next pointer or index of the immediately preceding content (content C ₂ ) identified. Further, since the content (content C ₃ ) is encoded and stored in the CS (belonging to the second node 102), the second node 102 can be configured to analyze the content (content C ₃ ). Also, the second node 102 may be configured to match the content (content C ₃ ) to a prefix of the previous content (e.g., content C ₂ ). If the prefix of the content C ₃ matches the prefix of the content C _2, C ₃ is the content of this determination for identifying whether or not the next content of the content C ₂ can be carried out in the following.

If the prefix of the content C ₃ does not match the prefix of the content C ₂ , then the packet of interest may be modified or modified and sent to an adjacent node (e.g., the second node 103).

In one embodiment, the determination may be performed by comparing the segment number of content C _{3 with} the segment number of content C ₂ .

The C ₃ content in order to determine whether the next content of the content C _2, C ₃ content difference between the segment number and the content of the segment number of the C ₂ may be one.

If the determination is true (e.g., content C ₃ indicates the next content of content C ₂ ), then verification may be performed by matching the content (content C ₃ ) to the remaining fields of interest . Once the remaining fields of interest are matched, the content C ₃ may be transmitted from the CS (belonging to the second node 102).

If the determination is false (e.g., content C ₃ does not point to the next content of content C ₂ ), then the packet of interest may be modified or modified and sent to an adjacent node (e.g., second node 103) Lt; / RTI >

The second node 102 may be configured to transmit the respective content associated with each request to the CCN engine 200 (belonging to the local CS (h = 0)) of the first node 101 after the PT. The local CS (h = 0) may be configured to store the received content for each request upon receipt of the content from the second node 102. Also. The CCN engine 200 of the first node 101 (belonging to the local CS (h = 0)) can be configured to transmit each received content to the first node 101.

5, the second node 102 may identify the content for Requests 2 to 5 and send the content to the CCN engine 200 (belonging to the local CS (h = 0)) of the first node 101 Lt; / RTI > The CCN engine 200 of the first node 101 (belonging to the local CS (h = 0)) can be configured to transmit each received content to the first node 101.

In addition, the modified attention packet may be changed once more at the second node 102 before being forwarded to the second node 103. In this example, the packet of interest 301b may be modified or changed to a window size of 4 (the number of requests in the packet of interest) and the request start segment number may be changed to 6.

The second node 103 may be configured to receive the modified attention packet 301b and may determine the number of requests in the modified interest packet. In addition, the second node 103 may be configured to process the modified attention packet 301b to identify the content associated with the request 6 to the request 9.

The second node 103 may be configured to process each request based on the information of the identified content for the previous request and may transmit the identified content to the second node 102, as described above. The second node 102 can be configured to store the received content and deliver the received content to the CCN engine 200 (belonging to the local CS (h = 0)) of the first node 101.

The CCN engine 200 of the first node 101 (belonging to the local CS (h = 0)) may store the received content in its CS and may finally transmit the content to the first node 101.

The technical contents described above with reference to Figs. 1 to 4 can be applied as they are, so that a more detailed description will be omitted below.

6 is a flow diagram illustrating a method for delivering content from a CS when a packet of interest according to an example includes a plurality of requests.

Figure 6 illustrates a method for delivering content from a CS. First, at step 601, a node of the CCN may be configured to receive a packet of interest that includes a plurality of requests.

In one embodiment, the packet of interest may include a window size indicating the number of requests in the packet of interest and a request start segment number.

When the node receives the packet of interest, in step 602, the node may be configured to decode and analyze the packet of interest. The node may also perform a validation check to determine whether duplicate and received packets of interest are correct. In one embodiment, the node may add the received attention packet to the forwarding table.

In step 603, the node may be configured to check the availability of content for a first one of a plurality of requests in a packet of interest within the CS (belonging to the node). If it is determined in step 603 that the content for the first request is available, then in step 604, the node may be configured to analyze the content for the first request. After analyzing the content in step 604, in step 605, the node extracts interest fields and exclude filters, such as the prefix of the packet of interest and the segment number of the content (received with the packet of interest) Etc. In one embodiment, the exclude filters may include content that includes components that match filters one level lower than the prefix length of interest, for example, Can be used to match interest, in order to exclude < / RTI > Such filters may include at least one element. These elements may also include a component name, a bloom filter, or any other element.

If the verification at step 605 is true (e.g., the content matches the fields of interest), then at step 606, the content for the first request may be delivered.

If the verification at step 605 is false (e.g., the content is not matched to the fields of interest), then the node may be configured to forward the packet of interest to the next node (adjacent node).

If the first content is transmitted, then in step 607, the node may be configured to use the next pointer to the recently identified content to obtain content for the next request (e.g., the second request).

In one embodiment, the content for the next request may be obtained by the node using the information of the identified content for the immediately preceding request.

If the next content for the next request is obtained using the next pointer or index of the identified content, then at 608, the next content is decoded Can be analyzed.

Also, at step 609, the content for the next request may be verified by matching the prefix of the content with the prefix of the identified previous content. If the verification at step 609 is false (e.g., the prefixes are not matched), then, at step 614, the node may be configured to modify the packets of interest and deliver the packets of interest to the neighboring nodes.

If the verification at step 609 is true (e.g., the prefixes are matched), then the node can be configured to determine whether the content for the next request is the next content of the immediately preceding content . Thus, in step 610, the node may be configured to compare the segment number of the next acquired content with the segment number of the immediately preceding content identified.

If the comparison of step 610 is true (e.g., the difference between the segment numbers is 1), then, at step 611, the node sends the next content obtained for the next request, e.g., Filters, and the like. ≪ RTI ID = 0.0 > In one embodiment, the exclude filters may be used to match interest to exclude content that includes components that match filters one level lower than the prefix length of interest. Such filters may include at least one element. These elements may also include a component name, a bloom filter, or any other element.

If the comparison at step 610 is false (e.g., the next content does not match the fields of interest), then the node modifies the node of interest and passes the node of interest to the next node (e.g., the adjacent node) .

If the comparison at step 611 is true (e.g., the next content matches the fields of interest), then at step 612 the next content obtained may be delivered. If the match at step 611 is false (e.g., the next content does not match the fields of interest), then, at step 614, the node modifies the packet of interest and sends the next node Node) to forward the packets of interest. The steps shown in Fig. 6 may be performed in the order shown or in a different order, or may be executed simultaneously. Also, in some embodiments, some of the steps shown in FIG. 6 may be omitted.

The technical contents described above with reference to Figs. 1 to 5 may be applied as they are, so that a more detailed description will be omitted below.

FIGS. 7A and 7B illustrate exemplary implementation setups for illustrating the performance gain when using the method of delivering content from a CS according to an example.

In Scenario 1 of FIG. 7A, all of the content may be received from the CCN content server (node 1). When the content is received from the CCN content server, the content is stored in the CS of the CCN content server as well as within the CS of node 2. In scenario 2 of Figure 7b, the next request for content may be performed from the local CS itself. Choosing a given setup may be based on the absence of networking overhead when the content is received from the local CS and therefore the throughput gain can only be obtained from the reduction of the overhead processing, And a platform for a fair comparison between the methods of the embodiments.

8A and 8B illustrate exemplary implementation setups to illustrate performance gain when using the method of delivering content from a CS according to an example.

In another scenario shown, networking delays can also be considered, and the performance can be compared. As in the scenario 1 shown in FIG. 8A, the CCN client node 1 can request the content from the CCN content server. Initially, because there is no content in the local CS of the CCN content server, the content may be received by the CCN client from the CCN content server. In scenario 3 of Figure 8b, another CCN client node 2 sends the same content to the CCN The CCN client node 2 can receive content from the CS of the CCN content server since all content is stored in the CS of the CCN content server.

FIG. 9 shows a comparison of the time at which content delivery from the CS was performed for the scenarios described above with reference to FIG. 7, according to an example.

A file size of 104MB was requested from the CCN content server. When the content is received from the CCN content server (first row of the table, scenario 1), the throughput values of the general method and the method of the embodiment may be approximately the same. When the content is received from the CS of the CCN client node 2 (scenario 2), the throughput gain of the method of the embodiment of the general method can be observed.

FIG. 10 shows a comparison of the time at which content delivery from the CS was performed for the scenarios described above with reference to FIG. 8, according to an example. The table shows the values related to the performance gain of the method and the general method of the embodiment. The benefit of the method of the embodiment to the general method in scenario 3 was 7.8%.

Figure 11 shows the average CS access time per attention for desktop machines according to an example. The illustrated comparison graph relates to the complete CS access time on the CCN server when the CCN client received all the content from the CC of the CCN server. After the total access time is obtained, the values are normalized by evaluating the average access time per interest and are shown in FIG. It has been observed that the larger the window size, the greater the difference in CS access time between the method of the embodiment and the general method.

Figure 12 shows average CS access time per interest for mobile devices according to an example. As the processing capabilities of the mobile devices are reduced, the approach time difference may increase further, as shown. In Fig. 12, two Android-based mobile devices are used. Similar to the case of using two PCs as described above with reference to FIG. 11, a decrease in the content access time was observed in the method of the embodiment. However, in the scenario using the mobile device rather than the scenario using the PC, Respectively.

13 illustrates a computing environment implementing a method for delivering content from a CS within a CCN according to an example. The computing environment 1301 includes a processing unit 1304 including at least one control unit 1302 and an arithmetic logic unit (ALU), a storage 1306 including a memory 1305 and a storage unit 1306 1309, a plurality of networking devices 1308 and a plurality of input / output (I / O) device (s) For example, the computing environment 1301 may correspond to a computer system. The processing unit 1304 may process the instructions of the algorithm. The processing unit 1304 may receive commands from the control unit to perform processing operations. Further, any logic and arithmetic operations associated with the execution of the instructions may be performed with the aid of the ALU 1303.

The computing environment 1301 may comprise a plurality of homogeneous and / or heterogeneous cores, a plurality of different types of central processing units (CPUs), special media, and other accelerators . The processing unit 1304 may process the instructions of the algorithm. Also, a plurality of processing units 1304 may be disposed on a single chip or a plurality of chips.

An algorithm consisting of the instructions and codes required for the implementation of the embodiment may be stored in either or both of the memory 1305 or the storage 1306. Upon execution of the instructions, the instructions may be fetched from the corresponding memory 1305 and / or storage 1306 and executed by the processing unit 1304.

A method of transferring content from the CS described above with reference to Figures 1-6 may be performed by the execution of the instructions.

In any hardware implementation, various networking devices 1308 or external I / O devices 1307 may be coupled to the computing environment to support this implementation through the networking unit and the I / O device unit.

The technical contents described above with reference to Figs. 1 to 6 can be applied as they are, so that a more detailed description will be omitted below.

The embodiments described above may be implemented through at least one software program that runs on at least one device and performs network management functions to control the elements. The elements shown in the preceding figures may include at least one hardware device or block (s), which may be a combination of hardware devices and software modules.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (19)

Receiving at least one packet of interest comprising a plurality of requests by a node in a content center network (CCN);
Checking availability of content within a content store (CS) for a first one of the plurality of requests;
Fetching available content for a sequential set of requests starting from the first one of the plurality of requests when content for the first request is available, The available content for each request of the remaining requests after the first request is fetched using information from the identified content for an immediately preceding request of each of the requests; And
Transmitting the retrieved available contents
The method comprising the steps of: The method according to claim 1,
Sending the at least one interesting packet to an adjacent node in the CCN to fetch the available content when the content for the first request is not available in the CS
≪ / RTI > The method according to claim 1,
Modifying the at least one packet of interest prior to sending the at least one packet of interest to an adjacent node based on availability of content for the set of sequential requests within the CS
≪ / RTI > The method of claim 3,
The step of modifying the at least one packet of interest
Wherein the at least one packet of interest changes at least one parameter of the at least one packet of interest by changing at least one of a number of requests that the at least one packet of interest includes and a request start segment number. The method according to claim 1,
The step of fetching the available content
Comparing the content for the first request with the fields of interest in the at least one packet of interest when the content for the first request in the CS is available,
Lt; / RTI >
The fields including at least one of a prefix of the at least one packet of interest and a segment number of the content,
The step of delivering the fetched available content
Transmitting content for the first request to a first node in the CCN requesting content for the first request when the content for the first request is matched to the fields
The method comprising the steps of: The method according to claim 1,
Wherein the information is indicative of an index or a pointer to an identified content for a previous request of the respective request. The method according to claim 1,
The step of fetching the available content
Matching the prefix of each piece of candidate content with the prefix of the previously identified content to identify the next content of previously identified content,
The method comprising the steps of: The method according to claim 1,
The step of fetching the available content
Determining content that is immediately followed by the previously identified content by comparing the segment number of each piece of content of the candidate content with the segment number of the previously identified content
The method comprising the steps of: 9. The method of claim 8,
A prefix of the previously identified content and a prefix of the content identified immediately after the previously identified content are matched,
Wherein the difference between the segment number of the previously identified content and the segment number of the content immediately following is one. A computer-readable recording medium containing a program for carrying out the method of any one of claims 1 to 9. A node for delivering content within a content center network (CCN)
An integrated circuit including at least one processor;
At least one memory comprising computer program code executed by the at least one processor;
Wherein the at least one processor when the computer program code is executed causes the node to perform a method,
The method comprises:
Receiving at least one packet of interest comprising a plurality of requests;
Checking availability of content within a content store (CS) for a first one of the plurality of requests;
Fetching available content for a sequential set of sequential requests starting from the first one of the plurality of requests when content for the first request is available, The available content for each request of the remaining requests after the first request is fetched using information from the identified content for an immediately preceding request of each of the requests; And
Transmitting the retrieved available contents
/ RTI > 12. The method of claim 11,
Wherein the node is configured to transmit the at least one interesting packet to an adjacent node in the CCN to fetch the available content when the content for the first request is not available in the CS. 12. The method of claim 11,
Wherein the node is configured to change the at least one packet of interest before sending the at least one packet of interest to an adjacent node based on availability of content for the set of sequential requests in the CS. 14. The method of claim 13,
Wherein the node is configured to change at least one parameter of the at least one packet of interest by changing at least one of a number of requests that the at least one packet of interest includes and a request start segment number. 12. The method of claim 11,
Wherein the node is configured to match the content for the first request with the fields of interest in the at least one packet of interest when the content for the first request in the CS is available,
The fields including at least one of a prefix of the at least one packet of interest and a segment number of the content,
Wherein content for the first request is sent to a first node in the CCN that requested content for the first request when the content for the first request is matched to the fields. 12. The method of claim 11,
Wherein the information represents an index or pointer of the identified content for the immediately preceding request of each of the requests. 12. The method of claim 11,
Wherein the node is configured to match a prefix of each content of candidate content to a prefix of the previously identified content to identify the next content of the previously identified content. 12. The method of claim 11,
Wherein the node is configured to determine content that is immediately followed by the previously identified content by comparing the segment number of each piece of content of the candidate content with the segment number of the previously identified content. 19. The method of claim 18,
A prefix of the previously identified content and a prefix of the content identified immediately after the previously identified content are matched,
Wherein the difference between the segment number of the previously identified content and the segment number of the content immediately following is one.

Images