Information-oriented network transfer device and program

Abstract

To provide an ICN transfer device that can deliver a requested object even if a wireless device moves.SOLUTION: A transfer device includes: management means for managing transfer information indicating a transmission destination device of a requested object; and processing means for performing notification processing for notifying a first transfer device of information indicating a first wireless device and information indicating a first requested object in which the first wireless device is indicated in the transfer information as the transmission destination device when receiving a first message indicating the first transfer device and the first wireless device from a control system of a mobile communication network, and change processing for changing the transmission destination device of the first requested object in the transfer information from the first wireless device to the first transfer device.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] This disclosure relates to a transfer device for an Information Centric Networking (ICN).

Background Art

[0002] An Information Centric Networking (ICN) that distributes content based on an identifier such as a name for specifying the content has been proposed. Non-Patent Document 1 discloses a Content Centric Networking (CCN), which is one type of ICN. Hereinafter, ICN will be described using CCN as an example.

[0003] In CCN, a server device that publishes content divides the content into objects called one or more chunks, and a client device acquires the content in units of these divided objects. Also, in CCN, a communication device that transfers an object (hereinafter referred to as a transfer device) can hold (cache) the object. When this transfer device receives an interest packet (request packet) requesting an object cached in its own device from a client device, it can transmit a data packet including the held object to the client device that is the source of the request packet without transferring the request packet to the server device.

[0004] The forwarding device manages the CS (Contents Store), FIB (Forwarding Information Base), and PIT (Pending Interest Table). The CS is information indicating the objects cached by the device. The FIB is information indicating the relationship between the object requested in the request packet (hereinafter referred to as the request object) and the output interface that forwards (outputs) the request packet. The PIT is information indicating the relationship between the receiving interface that received the forwarded request packet and the request object in that request packet.

[0005] For example, when using an IP network as the underlayer network for ICN, the output interface in the FIB will be the IP address of the device to which the request packet is forwarded, and the receiving interface in the PIT will be the IP address of the device that sent the request packet. In other words, when using an IP network as the underlayer network for ICN, the output interface in the FIB will indicate the next device (the next hop device) in the IP layer forwarding path of the request packet, and the receiving interface in the PIT will indicate the previous device (the previous hop device) in the IP layer forwarding path of the request packet.

[0006] When a forwarding device receives a request packet, it searches the CS (Customs Server) to determine whether it has cached the request object for that packet. If it has cached the request object, the forwarding device sends a data packet containing the cached request object to the device that sent the request packet. If it has not cached the request object, the forwarding device determines whether an entry for the request object exists in the PIT (Pickup Information Terminal). If an entry for the request object does not exist in the PIT, the forwarding device forwards the request packet based on the FIB (First Imaging Board) and adds an entry for the request object of the forwarded request packet to the PIT. This entry indicates the request object of the forwarded request packet and the receiving interface of the request packet or the device at the previous hop of the request packet. In this way, the PIT records request objects that are awaiting reception in the CCN (Customer Chain Network). If an entry for the request object of a received request packet exists in the PIT, the forwarding device does not forward the received request packet and adds the receiving interface of the request packet or the device at the previous hop of the request packet to an existing entry.

[0007] When a forwarding device receives a data packet containing a request object, it determines the destination of the data packet based on the PIT. The destination is the interface that received the request packet containing the request object or the device at the previous hop of the request packet. After forwarding the data packet containing the request object, the forwarding device removes the entry for the request object from the PIT. The forwarding device also updates the CS when it caches the request object contained in the data packet. In this way, in ICN, the request object is forwarded in the reverse direction along the same path as the request packet.

[0008] Non-patent document 2 discloses the application of ICN to mobile communication networks. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] V. Jacobson,et al.,"Networking Named Content",in Proceedings of ACM CoNEXT 2009,December 2009. [Non-Patent Document 2] J. Auge et.al., "Anchorless mobility management through hICN (hICN-AMM): Deployment options", Internet-draft, IETF, July 2020 [Overview of the Initiative] [Problems that the invention aims to solve]

[0010] Figure 1 shows an example system configuration when ICN is applied to a mobile communication network. The Radio Access Network (RAN) 2 includes multiple base stations and communicates wirelessly with the Radio Device (WD) 1. The User Plane Function (UPF) 3 terminates the PDU session with WD1. The PDU session is a virtual transmission path connecting WD1 and UPF3. WD1 sends and receives packets over the PDU session. In the following description, the UPF3 that has established a PDU session with WD1 will also be referred to as the UPF3 associated with that WD1.

[0011] ICN4 includes multiple forwarding devices. These forwarding devices may also be called ICN routers. The forwarding devices can be classified into edge ICN routers (ERs) 40 connected to UPF3 and other ICN routers (Rs) 41. In the following description, an ER40 connected to UPF3 will also be referred to as the ER40 associated with that UPF3. Furthermore, an ER40 associated with a UPF3 associated with WD1 will also be referred to as the ER40 associated with that WD1. Packets transmitted and received by WD1 to and from ICN4 are forwarded via the UPF3 and ER40 associated with WD1. ICN4 may also be connected to data networks (DNs) 51 and 52, such as the Internet.

[0012] Note that while Figure 1 shows three UPF3s, the number of UPF3s is not limited to three. Also, in Figure 1, ICN40 is connected to two DN51s and DN52s, but the number of DNs to which ICN40 is connected can be any number of one or more. Furthermore, while Figure 1 only shows three ER40s connected to three UPF3s and two R41s connected to two DN51s and DN52s, ICN4 may include other ICN routers. It is assumed that ICN4 uses the IP network as its underlayer network.

[0013] Figure 2(A) is an explanatory diagram of the process by which WD#1 acquires content via ICN4. In Figure 2(A), it is assumed that WD#1 has established a PDU session with UPF#1 via base station (BS)#1. UPF#1 is connected to ER#1. Therefore, UPF#1 and ER#1 are UPF3 and ER40, respectively, associated with WD#1.

[0014] Figure 3(A) shows the PIT held by ER#1 when WD#1 sends three request packets requesting objects OB#1 to OB#3, and ER#1 forwards the three request packets to R#3 according to the FIB. Assume that objects OB#1 to OB#3 have not been received from R#3. In each entry, the "Previous Hop" field records information that identifies WD#1, which is the hop in the IP layer that sent the request packet to ER#1, such as the IP address of WD#1. For example, when ER#1 receives a data packet containing object OB#1 from R#3, ER#1 forwards the data packet to WD#1 according to the PIT and removes the entry for object OB#1 from the PIT.

[0015] Figure 3(B) shows the state after WD#2 (not shown) has sent two request packets requesting objects OB#1 and OB#2, respectively, from the state shown in Figure 3(A). It is assumed that WD#2 has also established a PDU session with UPF#1. Because there are entries for objects OB#1 and OB#2 in the PIT, ER#1 does not forward the request packets received from WD#2, but adds information identifying WD#2 to the "previous hop" field of the entries for objects OB#1 and OB#2 in the PIT. In this case, for example, when ER#1 receives a data packet containing object OB#1 from R#3, ER#1 forwards the data packet to WD#1 and WD#2 according to the PIT and removes the entry for object OB#1 from the PIT.

[0016] Here, as shown in Figure 2(A), before objects OB#1 to OB#3 are delivered to WD#1, WD#1 moves and establishes a PDU session with UPF#2 via BS#2. Note that UPF#2 is connected to ER#2, not ER#1. When ER#1 receives a data packet containing object OB#1, it outputs the data packet to UPF#1 according to the PIT, with the destination being WD#1's address. However, because there is no PDU session between UPF#1 and WD#1, the data packet is not delivered to WD#1. In other words, objects OB#1 to OB#3 are not delivered to WD#1. Therefore, WD#1 must send three request packets to ER#2 again, requesting each of objects OB#1 to OB#3.

[0017] The above problem also occurs when WD#1 distributes content rather than retrieves it. Figure 2(B) is a diagram illustrating the process of WD#1 distributing content via ICN4. The connection relationships are assumed to be the same as in Figure 2(A). Figure 3(C) shows the PIT held by ER#1 when ER#1 receives three request packets from R#3 requesting objects OB#1 to OB#3 respectively, and ER#1 forwards the three request packets to WD#1 according to the FIB. Objects OB#1 to OB#3 are assumed to be undistributed. In each entry, the "Previous Hop" field records information that identifies R#3, which is the hop in the IP layer that sent the request packet to ER#1, such as the IP address of R#3. For example, when ER#1 receives a data packet containing object OB#1 from WD#1, ER#1 forwards the data packet to R#3 according to the PIT and removes the entry for object OB#1 from the PIT.

[0018] Here, as shown in Figure 2(B), before WD#1 distributes objects OB#1 to OB#3, assume that WD#1 has moved and established a PDU session with UPF#2 via BS#2. The data packets containing objects OB#1 to OB#3 sent by WD#1 reach ER#2, but since there are no entries for objects OB#1 to OB#3 in ER#2's PIT, ER#2 discards these data packets. Therefore, objects OB#1 to OB#3 are not distributed to the client device that requested them. Consequently, the client device resends a request packet requesting objects OB#1 to OB#3.

[0019] This disclosure provides an ICN transporter and program that can deliver requested objects even when the wireless device is in motion. [Means for solving the problem]

[0020] According to one aspect of the present disclosure, a transfer device in an information-oriented network includes a management means for managing transfer information indicating a destination device of a request object, and when receiving a first message indicating a first transfer device and a first wireless device from a control system of a mobile communication network, notifying the first transfer device of information indicating the first wireless device and information indicating a first request object in which the first wireless device is indicated as the destination device in the transfer information; and a processing means for performing a change process of changing the destination device of the first request object in the transfer information from the first wireless device to the first transfer device.

Advantages of the Invention

[0021] According to the present disclosure, even if the wireless device moves, the request object can be distributed.

Brief Description of the Drawings

[0022] [Figure 1] A diagram showing a configuration example when ICN is applied to a mobile communication network. [Figure 2] A diagram showing an example of content distribution when ICN is applied to a mobile communication network. [Figure 3] A diagram showing an example of a PIT held by ER#1 in FIG. 2. [Figure 4] A system configuration diagram according to some embodiments. [Figure 5] A sequence diagram when a wireless device acquires content according to some embodiments. [Figure 6] A diagram showing an example of a PIT held by an edge ICN router in the sequence of FIG. 5. [Figure 7] A sequence diagram when a wireless device distributes content according to some embodiments. [Figure 8] A diagram showing an example of a PIT held by an edge ICN router in the sequence of FIG. 7. [Figure 9] A diagram showing a content distribution path after a wireless device establishes a new PDU session according to some embodiments. [Figure 10] Configuration diagrams of a transfer device according to several embodiments. [Modes for carrying out the invention]

[0023] The embodiments will be described in detail below with reference to the attached drawings. Note that the following embodiments do not limit the invention as defined in the claims, and not all combinations of features described in the embodiments are essential to the invention. Two or more features from the multiple features described in the embodiments may be arbitrarily combined. Furthermore, identical or similar configurations will be given the same reference numeral, and redundant descriptions will be omitted.

[0024] Figure 4 shows the system configuration used to describe this embodiment. Note that components similar to those in Figure 1 are given the same reference numerals, and their descriptions are omitted. The control system 6 is a collective term for the network functions (NFs) of the control plane (CP) of the mobile communication network. Examples of NFs include the access and mobility management function (AMF) for managing the mobility of WD1, the session management function (SMF) for managing PDU sessions, and the policy control function (PCF) for managing policies.

[0025] The following description of this embodiment will be based on an example where, as shown in Figures 2(A) and 2(B), WD#1 has established a PDU session with UPF#1, but due to the movement of WD#1, the PDU session with UPF#1 is deleted, and instead, a PDU session is established with UPF#2. As shown in Figures 2(A) and 2(B), UPF#1 is connected to ER#1, and UPF#2 is connected to ER#2.

[0026] Figure 5 is a sequence diagram of the process when WD#1 retrieves content via ICN4. At the start of processing, WD#1 sends three request packets requesting objects OB#1 to OB#3, and ER#1 forwards the three request packets to R#3 according to the FIB. Figure 6(A) shows the PIT held by ER#1 at the start of processing. In Figure 6(A), it is assumed that WD#2, which has established a PDU session with UPF#1 (not shown), also sends two request packets requesting objects OB#1 and OB#2, respectively. The PIT has entries for each of objects OB#1 to OB#3. The "Previous Hop" field of the PIT is the same as in Figure 3(B). In this embodiment, a "Next Hop" field is provided in the PIT. The "Next Hop" field records information that identifies the device to which the request packets are forwarded, for example, the IP address of the destination device. According to Figure 5(A), the request packets requesting objects OB#1 to OB#3 are all forwarded to R#3.

[0027] The control system 6 manages the location of WD#1 in the mobile communication network. When the control system 6 detects that WD#1 is moving from a cell in BS#1 to a cell in BS#2, it determines that the termination destination of WD#1's PDU session should be switched from UPF#1 to UPF#2, and initiates a switching process to switch the PDU session. The control system 6 also determines that the ER associated with WD#1 will change from ER#1 to ER#2 as a result of this switching process. In response to this determination, the control system 6 sends a change notification message to ER#1 associated with WD#1 in S1. The change notification message includes information indicating WD#1, which is the target of the PDU session change, and information indicating ER#2, which will be newly associated with WD#1 as a result of the PDU session change.

[0028] In response to the change notification message, ER#1 interrupts the forwarding of the data packet to WD#1. For example, ER#1 interrupts the forwarding of the data packet to WD#1 by flagging the information indicating WD#1 in the "Previous Hop" field of the PIT entry (shown as an underline in Figure 6(B)), as shown in Figure 6(B). For example, in the state shown in Figure 6(B), when ER#1 receives a data packet containing object OB#1, it delivers the data packet to WD#2 according to the PIT, but postpones delivery to WD#1. Also, upon delivery of the data packet to WD#2, it removes the information indicating WD#2 from the "Previous Hop" field of the PIT entry for object OB#1, but does not delete the entry for object OB#1 because delivery to WD#1 is postponed. Furthermore, ER#1 buffers (or caches) the data packet containing object OB#1.

[0029] Next, ER#1 sends a message to ER#2 to create the first PIT entry. The message indicates the object of the PIT entry that ER#2 is instructed to create, and the device to be stored in the "previous hop" field of that entry. The object of the PIT entry that ER#2 is instructed to create is the object in ER#1's PIT entries that contains WD#1, the target of the PDU session switch, in the "previous hop" field. In other words, in Figure 6(B), these are objects OB#1 to OB#3. The device to be stored in the "previous hop" field of the entry to be created is WD#1, the target of the PDU session switch. ER#2 stores information indicating ER#1, the sender of the first PIT entry creation message, in the "next hop" field of the created entry. Therefore, in S6, ER#2 adds the entry shown in Figure 6(D) to the PIT.

[0030] Next, ER#1 modifies its own PIT in S4. Specifically, as shown in Figure 6(C), it changes the information indicating WD#1 in the "Previous Hop" field to information indicating ER#2, which is newly associated with the PDU session. Since the information of WD#1, which had been interrupting the forwarding of data packets, has been removed from the PIT, the forwarding interruption performed by ER#1 ends with this removal. As for data packets addressed to WD#1 that ER#1 received and buffered (or cached) before modifying its own PIT, it forwards them to ER#2 according to the modified PIT.

[0031] At the end of processing, ER#1 holds the PIT shown in Figure 6(C), and ER#2 holds the entry shown in Figure 6(D). Therefore, as shown in Figure 9(A), ER#1 forwards data packets containing objects OB#1 to OB#3 to ER#2, and ER#2 forwards data packets containing objects OB#1 to OB#3 to WD#1. This allows data packets to be delivered to WD#1 without retransmitting request packets, even if WD#1 moves.

[0032] Furthermore, if the device terminating the PDU session of WD#1 changes from UPF#1 to UPF#2, the IP address of WD#1 may also change. In such cases, the control system 6 notifies ER#2 of the new IP address of WD#1 in S5. In this case, the "previous hop" field of the PIT entry created by ER#2 will store the new IP address of WD#1.

[0033] Figure 7 is a sequence diagram of the processing when WD#1 delivers content via ICN4. At the start of processing, ER#1 receives three request packets from R#3, each requesting an object OB#1 to OB#3, and forwards these three request packets to WD#1 according to the FIB. Figure 8(A) shows the PIT held by ER#1 at the start of processing. The PIT has entries for each of the objects OB#1 to OB#3. The "Previous Hop" field of the PIT is the same as in Figure 3(C). In this embodiment, a "Next Hop" field is provided in the PIT. The "Next Hop" field records information that identifies the device to which the request packets are forwarded, for example, the IP address of the destination device. According to Figure 7(A), the request packets requesting objects OB#1 to OB#3 are all forwarded to WD#1.

[0034] Similar to S1 in Figure 5, in S10, the control system 6 sends a change notification message to ER#1. The change notification message includes information indicating WD#1, which is the target of the PDU session change, and information indicating ER#2, which will be newly associated with WD#1 due to the change in the PDU session. In response to the change notification message, ER#1 sends a second PIT entry creation message to ER#2 in S11. The second PIT entry creation message indicates the object of the PIT entry that instructs ER#2 to create, and the device to be stored in the "next hop" field of that entry. The object of the PIT entry that instructs ER#2 to create is the object in each PIT entry of ER#1 that contains WD#1, the target of the PDU session switch, in the "next hop" field. In other words, in Figure 8(A), these are objects OB#1 to OB#3. The device to be stored in the "next hop" field of the entry to be created is WD#1, the target of the PDU session switch. ER#2 stores information indicating ER#1, the sender of the second PIT entry creation message, in the "Previous Hop" field of the created entry. Therefore, in S14, ER#2 adds the entry shown in Figure 8(C) to the PIT.

[0035] Next, ER#1 modifies its PIT in S12. Specifically, as shown in Figure 8(B), it changes the information in the "Next Hop" field that indicates WD#1 to information that indicates ER#2, which is newly associated with WD#1. At the end of processing, ER#1 holds the PIT shown in Figure 8(B), and ER#2 holds the entry shown in Figure 8(C). Therefore, as shown in Figure 9(B), ER#2 forwards data packets containing objects OB#1 to OB#3, respectively, received from WD#1 to ER#1, and ER#1 forwards data packets containing objects OB#1 to OB#3, respectively, to R#3. This allows data packets to be delivered from WD#1 without retransmitting request packets, even if WD#1 moves.

[0036] Note that when the device terminating the PDU session of WD#1 changes from UPF#1 to UPF#2, the IP address of WD#1 may also change. In such cases, the control system 6 notifies ER#2 of the new IP address of WD#1 in S13. In this case, the "next hop" field of the PIT entry created by ER#2 will store the new IP address of WD#1.

[0037] Furthermore, in this embodiment, WD#1 is configured to set a flag in the header of the data packet carrying the request object when it sends a request object as a response to a request packet received in one PDU session in a different PDU session. Therefore, when WD#1 sends data packets containing objects OB#1 to OB#3 in a newly established PDU session with UPF#2, it sets the flag in the header of these data packets. Also, in this embodiment, ER40 is configured to buffer (or cache) a received data packet for a predetermined period of time if the flag is set in the header of the data packet, even if there is no entry in the PIT for the request object carried by the data packet. Therefore, for example, even if ER#2 receives a data packet containing object OB#1 from WD#1 before creating a PIT entry in S14, it does not discard the data packet, and after creating a PIT entry in S14, it forwards the data packet containing object OB#1 according to that entry.

[0038] Alternatively, for example, in the second PIT entry creation message sent by ER#1 in S11 of Figure 7, it is possible to configure the system to notify ER#2 of R3, which is stored in the "previous hop" field of ER#1, as the device to be stored in the "previous hop" field of the PIT entry to be created. In this case, ER#2 creates a PIT entry in S14 with R#3 stored in the "previous hop" field of Figure 8(C). Also, ER#1 deletes the PIT entry related to WD#1 in S12. In this case, when ER#2 receives a data packet containing object OB#1 from WD#1, it directly sends the data packet to R#3. When an IP network is used as an underlayer network, devices within ICN4 can send and receive packets to each other using IP addresses, thus reducing the number of devices that relay data packets.

[0039] In this embodiment, the reason PIT manages the next hop field is to accommodate the configuration in which WD#1 delivers content. In other words, as described in the sequence in Figure 7, ER#1 determines the request object for the entry that instructs ER#2 to create. Therefore, in configurations where WD#1 only acquires content and does not deliver it, there is no need for PIT to manage the next hop field.

[0040] Figure 10 is a diagram of the ER40 configuration. Communication interface 404 is a collective term for one or more communication interfaces provided on the ER40. The management unit 401 manages CS, FIB, and PIT. As described above, PIT is information indicating the destination device (transfer destination device) of the request object, and in this embodiment it is also referred to as "transfer information".

[0041] When the processing unit 403 receives a first message from the mobile communication network control system 6 indicating the first transfer device and the first wireless device, it performs the notification process and modification process described below. The first message corresponds to the modification notification message in S1 of Figure 5 and S10 of Figure 7. The notification process is the process of notifying the first transfer device of information indicating the first wireless device and information indicating the first request object in the transfer information in which the first wireless device is indicated as the destination device. This corresponds to the process in S3 of Figure 5. The modification process is the process of changing the destination device of the first request object in the transfer information from the first wireless device to the first transfer device. This corresponds to the process in S4 of Figure 5.

[0042] Furthermore, the transfer information may further indicate the source device that sends the request object to the transfer device. The source device that sends the request object to the transfer device is indicated in the next hop field of the PIT. Also, when the processing unit 403 receives the first message from the control system, in the notification process, it further notifies the first transfer device of the second request object, in which the first wireless device is indicated as the source device in the transfer information. This corresponds to the process in S11 of Figure 7. Furthermore, in the change process, the processing unit 403 changes the source device of the second request object from the first wireless device to the first transfer device. This corresponds to the process in S12 of Figure 7. Note that in Figures 5 and 7, the first PIT entry creation message and the second PIT entry creation message were treated as different messages, but it is also possible to configure the system to notify the first transfer device of the entries to be created with a single creation message. In other words, in response to receiving a change notification message from the control system 6, the processes in Figures 5 and 7 can be performed together.

[0043] The forwarding unit 402 forwards request packets and data packets based on information managed by the management unit 401. If the forwarding unit 402 receives a first data packet containing a first request object after receiving a first message from the control system and before the processing unit 403 completes notification and modification processing, it will hold the first data packet until the processing unit 403 completes notification and modification processing.

[0044] Furthermore, when the processing unit 403 receives a message from another transfer device indicating the addition of a first request object and a second request object, along with information indicating a wireless device of the mobile communication network, it performs an additional processing to add the first request object and the second request object to the transfer information. The destination device for the first request object is the wireless device, and the source device is the other transfer device. The destination device for the second request object is the other transfer device, and the source device is the wireless device.

[0045] Furthermore, the transfer unit 402 is configured to retain the data packet for at least a predetermined period of time if a predetermined flag is set in the header of the data packet, even if there is no entry for the request object carried by the data packet in the transfer information.

[0046] The ER40 described herein can be implemented by a computer program that, when executed on one or more processors of a device having one or more processors, causes the device to operate as an ER40. These computer programs are stored on a computer-readable storage medium or are distributed over a network.

[0047] The invention is not limited to the embodiments described above, and various modifications and changes are possible within the scope of the gist of the invention.

[0048] With the above configuration, requested objects can be delivered even when the wireless device is in motion. Therefore, it is possible to contribute to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), "Build resilient infrastructure, promote sustainable industrialization and foster innovation." [Explanation of Symbols]

[0049] 401: Administration Department, 403: Processing Department

Claims

1. A transfer device for an information-oriented network, A management means for managing transfer information indicating the destination device of a requested object, When a first message indicating a first transfer device and a first wireless device is received from a control system of a mobile communication network, the processing means performs a notification process to notify the first transfer device of information indicating the first wireless device and information indicating a first request object in which the first wireless device is indicated as the destination device in the transfer information, and a modification process to change the destination device of the first request object in the transfer information from the first wireless device to the first transfer device. A transfer device equipped with the following features.

2. When a data packet containing the aforementioned request object is received, the system further comprises a transfer means for transmitting the data packet according to the transfer information, The transfer device according to claim 1, wherein if the transfer means receives a first data packet containing the first request object after receiving the first message from the control system and before the processing means completes the notification processing and the modification processing, the processing means holds the first data packet until it completes the notification processing and the modification processing.

3. The transfer information further indicates a source device that transmits the request object to the transfer device, The transfer device according to claim 1, wherein, when the processing means receives the first message from the control system, in the notification process, the first wireless device notifies the first transfer device of the second request object indicated in the transfer information as the source device, and in the modification process, the source device of the second request object is changed from the first wireless device to the first transfer device.

4. The forwarding device according to claim 1, wherein the first message is transmitted by the control system when the control system changes the device that relays packets transmitted and received by the first wireless device from the forwarding device to the first forwarding device due to the movement of the first wireless device.

5. A program that, when executed on one or more processors of a device having one or more processors, causes the device to function as a transfer device according to any one of claims 1 to 4.

6. A transfer device for an information-oriented network, A management means for managing transfer information indicating the destination device of a requested object, Processing means for performing additional processing to add the destination device of the first request object to the transfer information in response to receiving a message from another transfer device indicating a first request object and a wireless device of a mobile communication network, Equipped with, The destination device of the first request object is a transfer device, which is the other transfer device or the wireless device.

7. The transfer information further indicates a source device that transmits the request object to the transfer device, The transfer device according to claim 6, wherein if the destination device of the first request object is the other transfer device, the source device of the first request object is the wireless device, and if the destination device of the request object is the wireless device, the source device of the first request object is the other transfer device.

8. The transfer device according to claim 6, wherein the message is transmitted by the other transfer device when the control system of the mobile communication network changes the device that relays packets transmitted and received by the wireless device from the other transfer device to the transfer device due to the movement of the wireless device.

9. The transfer device according to claim 8, wherein, when the wireless device moves, the device that relays packets transmitted and received by the wireless device is changed from the other transfer device to the transfer device, and the address of the wireless device is changed as a result, the transfer device receives the changed address of the wireless device from the control system.

10. A transfer device for an information-oriented network, A management means for managing transfer information indicating the destination and source devices of a requested object, Processing means for performing additional processing to add the destination device and source device of the first request object to the transfer information in response to receiving a message from the first transfer device indicating a first request object, a second transfer device, and a wireless device of a mobile communication network, Equipped with, A transfer device in which the destination device of the first request object is the second transfer device, and the source device of the first request object is the wireless device.

11. A program characterized in that, when executed on one or more processors of a device having one or more processors, the device functions as a transfer device according to any one of claims 6 to 10.

Images