Semantic routing for time-varying networks

Abstract

A semantic routing method (100) for a time-varying network, where the method (100) is configured to provide congestion-aware source-based routing to satellites, preferably LEO constellations, using a distributed name resolution system comprising-a plurality of routers,-a plurality of border routers, and-a service provider, where the border routers are configured to provide congestion-aware source-based routing to satellites, preferably LEO constellations, and the service provider is configured to provide congestion-aware source-based routing to satellites, preferably LEO constellations. The method (100) comprises an announcement stage, and the announcement stage comprises the following steps: (101) creating a border router sequence list of the plurality of border routers according to an increasing sequence of distances from the border routers to the current border router; (102) creating, by the current border router, a semantic data packet of a list of a plurality of instruction pairs; (103) executing, by the current border router, a first instruction on the list; and (104) receiving the semantic data packet by the plurality of routers, and executing the semantic data packet from the first instruction.

Description

Technical Field

[0001] The present invention relates to a semantic routing method for a time-varying network, which is a routing solution that uses a distributed name resolution system to provide congestion-aware source-based routing to satellites. Background Art

[0002] The routing protocols currently used in the Internet are expected to maintain simultaneous end-to-end connection paths on the network. Changes to this connectivity, such as the loss of an adjacent peer, require the routing protocol to respond to reduce the impact on network traffic.

[0003] However, there are an increasing number of use cases where predicted changes in the topology (recovery, activation, or loss) are an expected part of normal network operation. For example, in a network with mobile nodes such as aircraft (e.g., UAM, UAS, commercial aircraft) and spacecraft systems such as LEO constellations, links may be lost and re-established, or neighbors may change according to their mobility or resource availability. In such time-varying networks, traffic can be routed based on other metrics beyond hop count, such as energy cost or expected availability of services, which can vary predictably over time. In these cases, the predicted loss and recovery of neighbors, or the formation of alternative neighbors, should be considered non-disruptive events.

[0004] A clear example of a time-varying network is a LEO (Low Earth Orbit) satellite constellation. Under the assumption that satellites can communicate directly with each other in space using laser-based inter-satellite links (ISLs), LEO satellite constellations have been studied for decades to form a space-based optical mesh network. A typical path for Internet access includes an uplink with a radio frequency (RF) signal from a user terminal to a satellite, an optical path between satellites, and an RF downlink to a gateway connected to the Internet. Due to the rapid movement of satellites, frequent handovers between user terminals / gateways and satellites are expected.

[0005] For the operation of a LEO constellation, several networking aspects must be considered, namely the limitations and latency in handling packet loss, essentially determining requirements or finding suitable network paths in a network with dynamic connectivity and limited resources. In this case, a good routing solution is needed to provide good traffic distribution while paying attention to the flexibility of the network to cope with link or node failures.

[0006] In addition to networking and traffic aspects, other system considerations such as resource management can affect the performance of any solution aimed at routing traffic through a time-varying network. Such as: i) the on-board radio can be turned off to allow other nodes to process; ii) when devices are too close, such as satellites near the poles, the optical terminal can be turned off; iii) if there are thermal considerations on the node, the network function can be turned off. Such as the operating temperature of the node rising.

[0007] In the literature, various current routing algorithms for time-varying networks have been proposed, aiming to improve network throughput and reduce end-to-end latency while supporting reliable connectivity. For example, in the case of a LEO constellation, the goal is to use a routing framework that allows for the forwarding of large amounts of data over long distances through ISLs. However, the terrestrial core network is now quite robust and resource-rich, and multi-hop transmission through unstable ISLs will incur additional retransmission overhead. Therefore, how to route traffic through a LEO mega-constellation to provide ultra-reliable and low-latency communication services remains an open question and is thus the subject of this IDD.

[0008] Furthermore, in order to assume not only the dynamics of the network topology but also the required adaptation to services, a time-varying network should be able to adjust its network architecture and configuration based on service requirements and availability. In the future, novel routing methods for time-varying networks should be able to route traffic based on the service being transmitted (and invoked), rather than focusing on the devices that request and provide such services.

[0009] In this section, we focus the analysis of the prior art on the specific use case of time-varying networks, satellite LEO constellations. However, the same solutions can be applied to other scheduled time-varying networks, such as networks where devices move based on a predefined route (e.g., commercial aircraft).

[0010] Routing in satellites is typically mapped to two categories: snapshot routing and dynamic routing. In the former case, it is assumed that the topology of the satellite constellation is static or the duration of the snapshot, and then routing is performed on this static topology. Due to the different latencies (on the order of milliseconds) of packet transmission and the movement of the satellites (which is several minutes for ground stations), this assumption is reasonable. As the topology evolves, a new routing table is populated for the next snapshot. The routing table can usually be pre-computed and uploaded in a central server to minimize the processing workload in the satellite.

[0011] In "Topological design and routing for low-Earth orbit satellite networks" published by Hong Seong Chang, Byoung Wan Kirn, Chang Gun Lee, Yanghee Choi, SangLyul Mm, Hyun Suk Yang, and Chong Sang Kirn in 1995 (in the proceedings of GLOBECOM '95), a snapshot-based solution has been proposed. They observed that the topology of the satellite constellation follows a finite number of possible states. Thus, a finite state automaton (FSA) can be constructed in advance. For each state, the configuration can be pre-computed and loaded into the satellite, which means that the satellite itself does not have to perform the calculations, but only load the topology configuration and routing corresponding to a specific state. This snapshot-like method is also elaborated in "Routing in LEO-based satellite networks" by V.V. Gounder, R. Prakash, and H. Abu-Amara in 1999 (in the proceedings of the 1999 IEEE Workshop on Emerging Technologies: Wireless Communications and Systems (Proceedings Number IEEE Catalog Number 99EX297)). IEEE 22.1 - 22.6 defines similar states, called snapshots, which correspond to the topology of the satellite network at a specific moment. Each satellite stores routing information corresponding to several snapshots, which are uploaded from the ground station regularly. A similar but method that relies on computing snapshots on a centralized server is the Contact Graph Routing (CGR) proposed by Juan Andres A Fraire, Olivier de Jonckere, and Scott C Burleigh in "Routing in the Space Internet: A contact graph routing tutorial" (in the Journal of Network and Computer Applications (JNCA) in 2021). This method focuses on scheduling Delay-Tolerant Networks (DTN), and such networks can utilize contact plans containing future network connectivity to make efficient forwarding decisions.In CGR, the centrally computed contact plan is uploaded to all satellites, enabling each satellite to use Dijkstra's algorithm and the contact plan to calculate the shortest route to any other satellite in the system.

[0012] Other routing solutions based on computing the shortest path are based on the Open Shortest Path First (OSPF) protocol (IETF rf02328), which has been extended to accommodate the specific properties of low Earth orbit (LEO) constellations. An example is the Area-based Satellite Routing Protocol (ASER), which was published by Xiang Zhang, Yuan Yang, Mingwei Xu, and Jing Luo in 2021 at the 46th IEEE Local Computer Networks Conference (LCN), "ASER: Scalable Distributed Routing Protocol for LEO Satellite Networks", which is a hierarchical packet method for satellites within a region. The basic assumption of ASER is that the topology within a region is static, in which case ASER is used to dynamically connect these regions. Another example is Orbit Prediction Shortest Path First (OPSPF), which was published by Tian Pan, Tao Huang, Xingchen Li, Yujie Chen, Wenhao Xue, and Yunjie Liu in 2019 at the IEEE International Conference on Communications (ICC), "OPSPF: Orbit Prediction Shortest Path First Routing for Resilient LEO Satellite Networks", which extends OSPF by considering the periodic predictability of orbits. This addresses the problem of endless routing convergence consuming expensive inter-satellite link bandwidth in OSPF.

[0013] All these solutions for calculating the shortest path based on contact plan information, such as CGR and other solutions based on OSPF and Dijkstra, seem to work well as long as the network remains small or medium-sized. G. Wang, S. C. Burleigh, R. Wang, L. Shi, and Y. Qian published the article "Scoping contact graph-routing scalability: Investigating the system's usability in space-vehicle cornmunication networks" in the IEEE Vehicular Technology Magazine, Vol. 11, No. 4, pp. 46-52, in December 2016. So far, in these methods, the workload of routing calculation and its impact on network scalability have been regarded as secondary objectives.

[0014] To address the scalability issue, a common strategy is to divide a large LEO satellite constellation into several regions and use Dijkstra or similar algorithms within each region to identify the shortest path between any pair of satellites. Hou Dongxu, Xiao Min, and Fenlin Zhou published "Routing Framework for LED Mega-constellation Based on Region Division" in the IETF draft (draft-hou-rtgwg-satellite-routing-framework-00) in July 2023. There are also some proposals that focus on using Dijkstra or similar algorithms to coordinate routing between different regions based on an abstract model where each network node represents a region. Pablo G. Madoery, Juan A. Fraire, Fernando D. Raverta, Jorge M. Finochietto, Scott C. Burleigh published "Managing Routing Scalability in Space DTNs" in the proceedings of the IEEE International Conference on Wireless in Space and Extreme Environments (WiSEE) in 2018.

[0015] An alternative to snapshot-based solutions is to design a dynamic routing protocol, based on which the satellites forward data packets based on the current network configuration. This means that the routing protocol must adapt dynamically to changes in the topology, since the stabilization time of snapshots is rather short, which is similar to the problem of characterizing path stability in other types of time-varying networks, such as ad hoc networks. Claude Richard, Charles E. Perkins, and Cedric Westphal published "Defining an optimal active route timeout for the AODV routing protocol" in the proceedings of the Second IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks (IEEE SECON, 26-29) in 2005.

[0016] An example could be to adapt well-known dynamic routing protocols, such as AODV (IETF rfc3561), to satellite networks. In this context, the Location-Aided On-Demand Routing (LAOR) protocol, presented by E. Papapetrou, S. Karapantazis, and F.-N. Pavlidou in "Distributed on-demand routing for LED satellite systems" in Computer Networks, Volume 51, Issue 15 (2007), pages 4356-4376, independently or for each communication request invokes a shortest path discovery procedure independently, which incurs significant overhead. For highly dynamic topologies, protocols that allow some path flexibility around short paths (such as OPRAH), may be more advantageous than AODV. For example, the OPRAH protocol in "Opportunistic Routing in Dynamic Ad Hoc Networks: the OPRAH protocol" by Cedric Westphal in the IEEE International Conference on Mobile Ad Hoc Networks and Sensor Systems in 2006.

[0017] To bring some flexibility to snapshot and dynamic routing protocols so that they can handle link failures, some protocols use repair strategies such as the Destruction-Resistant On-Demand Routing protocol (DODR), which was introduced by Xuezhi Ji, Lixiang Liu, Pei Zhao, and Dapeng Wang in "A destruction-resistant On-demand routing protocol for LEO satellite network based on local repair" published in the 12th International Conference on Fuzzy Systems and Knowledge Discovery (FSKD, 2013 - 2018) in 2015. It is a self-organizing protocol that utilizes route replies (RREPs in AODV) and local repair strategies during the path discovery process to quickly identify and repair broken paths without incurring heavy overhead. Another example is the Disruption Tolerant Distributed Routing (DTDR) protocol, which was introduced by Jifeng Jin, Feng Tian, Zijian Yang, Hao Di, and Guotong Li in "A Disruption Tolerant Distributed Routing Algorithm in LEO Satellite Networks" published in Applied Sciences, Volume 12, Issue 8 (2022). It can respond to failures by broadcasting only the information of the failed link (instead of link state updates), thereby reducing overhead, taking advantage of the relatively static (or periodic) grid topology of the satellite constellation.

[0018] While all these protocols aim to provide failure recovery by ensuring fast convergence times, another approach might be to avoid any reliance on topological information and instead rely on geographic information. For example, there have been proposals for routing mechanisms that select the next hop based on minimizing the remaining Euclidean distance to the destination, as presented by T.R. Henderson and R.H. Katz in their paper "On distributed, geographic-based packet routing for LED satellite networks" at the 2000 IEEE Global Telecommunications Conference (Globecom '00, Proceedings (Catalog Number 00CH37137), Volume II). Under normal conditions, geographic routing is close to the optimal path (limiting latency differences to within 10 milliseconds). However, such protocols can fail at reverse-rotating seams, polar regions, and near the packet's destination.

[0019] Geographic routing has been considered for handling many other time-varying topologies, such as ad hoc networks, as presented by Julien Herzen, Cedric Westphal, and Patrick Thiran in their paper "Scalable Routing Easy as PIE: a Practical Isometric Embedding Protocol" at the 2011 IEEE ICNP conference. The benefit of geographic routing is that the routing is extremely simple; once the relative positions of the current node, its neighbors, and the destination are known, selecting the neighbor closest to the destination is a simple calculation. This seems well-suited for satellite networks, as satellites have limited resources but know their geographic location. However, in satellite networks, the destination (on the ground) is not static relative to the moving constellation. The topology also changes between ascending and descending satellites, which means that using other types of addressing information in addition to the device's geographic location might be beneficial.

[0020] This requirement of using different address semantics is also consistent with the expectation that different future satellite systems need to interoperate. Therefore, it may be appropriate to define protocols for satellite Internet based on instruction routing and semantic addressing, as published by Lin Han, Richard Li, Alvaro Retana, chenmeiling, Li Su, and Ning Wang in the Internet draft "Problems and Requirements of Satellite Constellation for Internet" (draft-Ihan-problems-requirements-satellitenet-05) in July 2023. By using the semantic addresses of LEO satellites, Lin Han, Alvaro Retana, and Richard Li published "Semantic Address Based Instructive Routing for Satellite Network" in the Internet draft (draft-lhan-satellite-instructive-routing-03) in September 2023. Packet forwarding can be just a simple instruction like "forward the packet in the specified direction until it reaches the specified satellite". Compared with traditional hop-by-hop IP packet forwarding (longest prefix match lookup based on the routing table), the new solution can better adapt to very dynamic network topologies, while the packet overhead is less than that of IPv6 Segment Routing (SRv6). Summary of the Invention

[0021] The aim is to operate based on semantics such as geographical location, IP address, service name, information about congestion, etc.

[0022] Another aim is to have an embedded distributed system for resolving service names into semantic addresses.

[0023] Another aim is to use source-based routing so that satellites implement a simple routing engine.

[0024] Another aim is to operate based on geographical routing, which can adapt to network dynamics and forward traffic via a group of satellites as close as possible to the destination.

[0025] Another aim is to be able to route traffic around congested satellites if congestion is detected.

[0026] Another aim is to be able to support multicast traffic by making the semantic address include multiple destinations.

[0027] These objectives are achieved by the subject matter of the independent claims. Exemplary embodiments will be found in the dependent claims and the following description.

[0028] According to one aspect, there is provided a semantic routing method for a time-varying network, wherein the method is configured to provide congestion-aware source-based routing to satellites (preferably LEO constellations) using a set distributed name resolution system. A plurality of routers, a plurality of border routers, and service providers are provided.

[0029] The method includes an advertisement phase, which includes the following steps: Create a border router order list of the plurality of border routers in ascending order of distance from the current border router; Create, by the current border router, a semantic data packet of a list of a plurality of instruction pairs of the following types: Forward (Forward.pkt.areaID) the semantic data packet to a specific geographical area with the geographical location ID of the geographical area of the destination border router; Broadcast (Forward.pkt.servID) the semantic data packet to a specific service ID of the IP addresses of the plurality of border routers with a radius of R; End (Forward.pkt.end) the execution instruction; Execute, by the current border router, the first instruction on the list; Receive, by the plurality of routers, the semantic data packet and start executing from the first instruction, wherein: - If the router is not in the geographical area of the destination border router, further forward the semantic data packet to an adjacent router; or - If the router is in the geographical area of the destination border router, broadcast the semantic data packet within the geographical area until it reaches a router having a connection or termination radius R with the destination border router, wherein the router having a connection or termination radius R with the destination border router sends the payload of the semantic data packet to the current border router, and the router having a connection or termination radius R with the destination border router executes the following instruction in the semantic data packet, and all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

[0030] The method further includes a forwarding phase, wherein the information previously exchanged between the plurality of border routers is used to forward data packets, and the forwarding phase is configured to be executed in an active mode or a response mode, wherein: In the active mode, the multiple border routers trigger their own semantic data packets, which have path discovery messages to a specific service, in order to identify the most suitable path, where the information about the identified path is placed in the local routing table and used as a label in future semantic data packets, thus allowing for faster forwarding within a time-varying network, and In the response mode, the multiple border routers trigger the transmission of semantic data packets to carry the packets received from the interfaces connected to the external network, where the multiple border routers create semantic data packets forwarded by routers that do not store any state during this process, where the semantic data packet includes a header and a payload, the header having the IP address of the border router as the source address and the IP address of the destination service, the payload having the received packet and an extension header, the extension header allowing the payload to be distributed in unicast mode, such that the method (100) operates based on geographic routing, which is capable of adapting to network dynamics and forwarding traffic via a set of satellites as close as possible to the destination.

[0031] Compared with other methods aimed at routing traffic on a LEO satellite constellation, the present invention has the following benefits: - Operating based on semantics such as geographical location, IP address, service name, information about congestion. - Having an embedded distributed system for resolving service names into semantic addresses. - Using source-based routing, enabling the satellite to implement a simple routing engine. - Operating based on geographic routing capable of adapting to network dynamics and forwarding traffic via a set of satellites as close as possible to the destination. - Being able to route traffic around congested satellites if congestion is detected - Being able to support multicast traffic by allowing semantic addresses to include multiple destinations.

[0032] The router is responsible for forwarding semantic data packets (with payloads related to packets and border state announcements). To support these actions, the router needs to perform internal operations to estimate its location and congestion level. The operations of the router are divided into two states: packet forwarding and state calculation. The former is triggered by the reception of semantic data packets, while the latter is triggered periodically.

[0033] Based on the internal timer and the information carried in the header (and extender header) of the semantic data packet, the router implements the following operations: - Receiving packets: This function is triggered by receiving semantic data packets from adjacent nodes. The router first checks whether the packet has an extension header.

[0034] If so, it executes the instructions stored in the extension header. - Internal trigger: - Congestion function: - Estimate its congestion level by analyzing the status of the networking queue, storage (if any), and power level at configured time intervals. - Broadcast the current congestion level to all neighboring nodes. - Geographical location function: - Estimate its geographical location by querying the locally installed GPS device at configured time intervals - Broadcast the estimated geographical location value to neighboring nodes.

[0035] The border router is responsible for docking the time-varying network with other IP networks that can exchange data packets. The operations of the border router include the following functions: - Local configuration: - Identify its exact geographical location and the geographical location of the geometric area in which it is deployed.

[0036] Store information about all other service edges of the time-varying network (provided by the network operator via the configuration interface). This information includes: service edge ID; service edge geographical location. - Service registration function: - Receive the registration of service instances from any network provider. The service instance is a service instance identified by its name and the IP address on which the service is running. In the case where the service registration requires local installation of the service instance, the IP address can be that of the service edge. - Store service instance information based on the tuple (service name; IP address). - Border status announcement: - Propagate the service edge information of all known registered service instances, i.e., their service names and the geographical location information of the announced service edge, as well as the geographical identification of the geometric area of the service edge in which they are deployed. - Receive and store information about service instances registered in other service edges. - Gateway function: - Receive data packets directly sent from external devices of the time-varying network to a specific service identified by name. Encapsulate these data packets into semantic data packets for forwarding to selected services inside the time-varying network. - Receive semantic data packets from internal routers. In this case, the gateway processes the payload carried and forwards the data packet to the destination identified in the data packet header.

[0037] Service providers can register multiple different instances of the same service in different service edges based on their reliability policies.

[0038] According to one embodiment, performing the forwarding phase in response mode includes the following steps: The plurality of border routers receive semantic data packets from an external network.

[0039] According to one embodiment, the method further includes the following steps: The plurality of border routers use the service name carried in the received data packet to check the locally stored information to identify the border router hosting the service.

[0040] According to one embodiment, the method further includes the following steps: Select a specific hosting border router based on the configured forwarding policy from the list of possible hosting border routers.

[0041] According to one embodiment, the method further includes the following steps: The plurality of border routers create semantic data packets having the following routing instructions in the extension header: - Forward the data packet (Forward.pkt.areaID) to a specific geographical area with the geographical location ID of the geographical area having the destination border router; - Broadcast (Forward.pkt.servID) the data packet to a specific service ID, where the data packet is forwarded using a radius R to the service ID (IPv6 address) indicated in the data packet header; - End (Forward.pkt.end) the execution instruction. The plurality of border routers execute the first instruction on the list.

[0042] According to one embodiment, the method further includes the following steps: The plurality of border routers receive the semantic data packet and start executing from the first instruction, where: - If the router is not in the geographical area of the destination border router, forward the semantic data packet to an adjacent router that is geographically closer to the destination and least congested; or - If the router is in the geographical area of the destination border router, broadcast the semantic data packet within the geographical area until it reaches a router having a connection with the service ID indicated in the data packet header or until the radius R terminates, where the router sends the payload of the semantic data packet to the border router, and all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

[0043] According to one embodiment, performing the forwarding phase in active mode includes the following steps: Select one of the locally installed services by the plurality of border routers.

[0044] According to one embodiment, the method further comprises the steps of: Create a semantic data packet having the following routing instructions in the extension header by the plurality of border routers: - Collect (Discover.path.to.areaID) information about routers in the path to a specific geographical area with a geographical location ID towards a geographical area having a destination border router; - Create (Create.reverse.pkt) a new semantic data packet; - End (Forward.pkt.end) the execution instruction; Execute the first instruction on the list by the plurality of border routers.

[0045] According to one embodiment, the method further comprises the steps of: Receive a semantic data packet by the plurality of border routers and start execution from the first instruction, wherein: - If the router is not in the geographical area of the destination border router, the router: i. Identify an adjacent router that is geographically closer to the destination and least congested; ii. Add the ID of the selected adjacent node to the head of the router address chain in the packet payload; iii. Forward the semantic data packet to the selected adjacent router; Or - If the router is in the geographical area of the destination border router, the router adds its ID to the head of the router address chain and executes the next instruction.

[0046] According to one embodiment, the method further comprises the steps of: Create a new semantic data packet by the destination router, with the current router's IP address as the source address, the service ID carried in the previous packet as the destination address, the chain index in the data packet header as 1, including the following instructions: - Forward (Forward.pkt.chainID) the semantic data packet to a specific geographical area having a router address chain collected from the received semantic data packet; - Store (Stores.chain.servID) information about the received router chain; - End (Forward.pkt.end) the execution instruction.

[0047] According to one embodiment, the method further comprises the steps of: The first instruction is executed by the destination router.

[0048] According to one embodiment, the method further comprises the steps of: The first instruction on the list is executed by the plurality of border routers to forward the semantic packet to the router with the first IP address indicated in the instruction, and increment the chain index by 1.

[0049] According to one embodiment, the method further comprises the steps of: The second instruction is executed by the plurality of routers that receive a semantic packet having a chain index greater than the size of the router address chain, and the router address chain associated with the service is stored, the ID of the service being indicated as the destination IP in the data packet header.

[0050] According to one embodiment, wherein for all services having a non-empty router address chain, the border router will use the following process to forward packets: The border router receives a packet from an external network; The border router uses the service name carried in the received packet to check the locally stored information to identify the router address chain associated with the service; The border router creates a semantic packet with a header and the following routing instructions, wherein the header has the IP address of the border router as the source address and the service ID of the selected service as the destination address, and the routing instructions include: - Forward the packet (Forward.pkt.chainID) via a set of known routers, wherein the router address chain is locally stored for the received service name; - Broadcast the semantic packet (Foward.pkt.servID) towards a specific service ID, wherein the packet is forwarded to the service ID (IPv6 address) indicated in the data packet header using a radius R; - End (Forward.pkt.end) the execution instruction; The first instruction on the list is executed by the border router; The plurality of routers receive the semantic packet and start executing from the first instruction, wherein, if the router address chain is not empty, the router removes the first address from the router address chain and forwards the resulting packet to the adjacent router with that IP address.

[0051] According to one embodiment, if the router address chain is empty, the router broadcasts semantic packets until it reaches a router having a connection with the service ID or until the radius R terminates, where the router sends the payload of the semantic packet to a border router that can be reached via an interface configured with the service ID, and all routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic packet.

[0052] In other words, a semantic routing method for time-varying networks that uses a distributed name resolution system to provide a congestion-aware source-based routing solution to a satellite LEO constellation.

[0053] The proposed mechanism allows traffic to be forwarded in time-varying networks such as LEO constellations by using semantic addresses constructed from a combination of the geographical location of the area where the destination is located plus the IPv6 address identifying a specific service instance. In this sense, the proposed solution is different from previous semantic routing for satellite systems, which proposed a routing method based on satellite semantic addresses. In the proposed solution, there is no need to identify satellites and track their positions in the network topology.

[0054] The proposed routing solution allows time-varying networks such as LEO constellations to be deployed without knowledge of location-based addressing, since the address semantics involve the service being invoked (geographical location and identifier). To reduce the latency required for using traditional name resolution systems (e.g., Domain Name Service (DNS)), the proposed routing protocol covers the required signaling to allow edge routers to create semantic addresses based on the requested service name.

[0055] Time-varying networks cover a set of mobile nodes (operating as routers), each having a set of point-to-point or omnidirectional wireless interfaces (e.g., radio links or free-space optical links) to adjacent nodes. Some nodes of the time-varying network may have interfaces to gateway nodes (operating as border routers) that provide connectivity to non-time-varying networks.

[0056] Assume that the Earth's surface is divided into circular geometric regions with equal radii (configured values) and identified by the geographical location of their centers. Also assume that routers and border routers are aware of this division of the Earth's surface and that: Border routers can be deployed at fixed positions inside certain geometric regions or can move inside and between geometric regions. Examples can be satellite ground stations or mobile satellite terminals. Routers can switch between adjacent geometric regions based on predefined paths (e.g., satellite orbits or aircraft routes / missions). Examples can be satellites or aircraft.

[0057] During the announcement phase, the border router announces information about locally installed services to all known border routers. In this operation, the border router creates a semantic packet with the IP address of the border router as the source address and the IP address of the ultimately destination border router as the destination address. The created semantic packet has a payload that has a list of data items identifying the local service, where each item covers: - Service name - Service ID (IPv6 address) - Geographic location ID of the border router's geographic area

[0058] Create a semantic packet with an extended header that allows the payload to be distributed in multicast form.

[0059] The announcement phase includes the following steps: 1. The list of border routers in order of known border routers is sorted in ascending order of their distance to the current border router. 2. The border router creates a semantic packet with a list of multiple pairs of instructions of the following types: Forward.pkt.areaID, which has the geographic location ID of the geographic area of the destination border router; Forward.pkt.servID, where the IP address of the border router has a radius R; The list ends with the instruction Forward.pkt.end. The resulting list of instructions has twice the number of entries in the list created in step 1 + 1. 3. The border router executes the first instruction on the list. 4. The router receives the semantic packet and starts executing from the first instruction. The following actions can occur: - The router is not in the geographic area of the destination border router. In this case, it further forwards the semantic packet to an adjacent router. - The router is in the geographic area of the destination border router. In this case, the semantic packet is broadcast within the geographic area until it reaches a router with a connection to the destination border router or the radius R terminates. In the former case, the router sends the payload of the semantic packet to the border router. And the router executes the following instruction in the semantic packet. All other routers within the geographic area execute the last instruction (Forward.pkt.end) carried in the semantic packet.

[0060] During the forwarding phase, the information previously exchanged between border routers is used to forward packets in two modes: response mode and proactive mode.

[0061] Response mode: The border router forwards the packet to the selected service based on the semantic packet. The forwarded semantic packet does not leave the state in the router. This phase is triggered by receiving a packet from a client outside the time-varying network.

[0062] Proactive mode: In this case, the border router triggers itself to send a semantic packet with a path discovery message to a specific service (e.g., with low latency requirements) in order to identify the most suitable path. Information about the identified path is placed in the local routing table and used as a label in future semantic packets, aiming to allow faster forwarding within the time-varying network.

[0063] In response mode, the border router triggers the transmission of a semantic packet to carry the packet received from the interface connected to the external network. In this operation, the border router creates a semantic packet forwarded by a router that does not store any state during the process. The semantic packet has a header and a payload, where the header has the IP address of the border router as the source address and the IP address of the destination service (after the resolution step, as described below), and the payload has the received packet and an extended header that allows the payload to be distributed in unicast mode.

[0064] The forwarding phase operating in response mode includes the following steps: 5. The border router receives a packet from the external network. 6. The border router uses the service name carried in the received packet to check the locally stored information to identify the border router hosting the service. 7. Based on the list of possible hosting border routers, a hosting border router is selected based on the configured forwarding policy. 8. The border router creates a semantic packet with the following routing instructions in the extended header: - Forward.pkt.areaID, which has the geographical location ID of the geographical area of the destination border router. - Forward.pkt.servID, which forwards the packet to the service ID (IPv6 address) indicated in the data packet header using a radius R. - Forward.pkt.end. 9. The border router executes the first instruction on the list. 10. The router receives the semantic packet and starts executing from the first instruction. The following actions can occur: - The router is not in the geographical area of the destination border router. In this case, it forwards the semantic packet to the adjacent router that is geographically closer to the destination and has the least congestion (based on the information collected from the periodic information received from adjacent nodes). - The router is in the geographical area of the destination border router. In this case, the semantic packet is broadcast within the geographical area until it reaches a router with a connection to the service ID indicated in the data packet header (destination address) or until the radius R terminates. In the former case, the router sends the payload of the semantic packet to the border router. All routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic packet.

[0065] An example of a forwarding strategy is load balancing. In this case, the border router selects the border router to which it has sent fewer packets in the past as the next border router. Different forwarding strategies can be used for different types of services.

[0066] In the active mode, the border router triggers the transmission of semantic packets to discover the best path to one or more services whose information is locally stored.

[0067] In this operation, the border router creates a semantic packet that is forwarded by routers that do not store any state during the process. The semantic packet has the IP address of the border router as the source address, the service ID (IPv6 address) as the destination address, and an extension header that allows the payload to be distributed in unicast mode. And it starts with the payload, covering a chain of router addresses that starts with the IP address of the source border router.

[0068] The forwarding phase operating in the active mode has the following steps: 1. The border router selects one of the locally installed services. 2. The border router creates a semantic packet in the extension header with the following routing instructions: - Discover.path.to.areaID, with the geographical location ID of the geographical area of the destination border router. - Create.reverse.pkt. - Forward.pkt.end. 3. The border router executes the first instruction on the list. 4. The router receives the semantic packet and starts executing from the first instruction. The following actions occur: - The router is not in the geographical area of the destination border router. In this case: i. Identify the neighboring router that is geographically closer to the destination and least congested. ii. Add the ID of the selected neighboring node to the head of the router address chain in the packet payload. iii. Forward the semantic packet to the selected neighboring router. - The router is in the geographical area of the destination border router. In this case, the router adds its ID to the head of the router address chain and executes the next instruction. 5. The destination router creates a new semantic packet with the current router's IP address as the source address, the service ID (IPv6 address) carried in the previous packet as the destination address, and a chain index of 1 in the data packet header, including the following instructions: - Forward.pkt.chainID, where the router address chain is collected from the received semantic packet. - Stores.chain.servID. - Fwd.pkt.End. 6. The destination router executes the first instruction. 7. The router executes the first instruction on the list, forwards the semantic packet to the router whose IP address is the first one indicated in the instruction, and increments the chain index by 1. 8. The router that receives a semantic packet with a chain index greater than the size of the router address chain (which indicates that the router is the source border router) executes the second instruction, i.e., stores the router address chain associated with the service, and the ID of the service is indicated as the destination IP in the data packet header.

[0069] Repeat this process for all services for which the border router wants to have a faster response (e.g., lower latency) when the packet arrives.

[0070] For all services with a non-empty router address chain, the border router will use the following process to forward the packet: 1. The border router receives a packet from the external network. 2. The border router uses the service name carried in the received packet to check the locally stored information to identify the router address chain associated with the service. 3. The border router creates a semantic packet with a header and the following routing instructions, where the header has the border router's IP address as the source address and the service ID (IP v6 address) of the selected service as the destination address, and the routing instructions include - Forward.pkt.chainID, where the Reuter address chain is locally stored for the received service name. - Foward.pkt.servID, where the data packet is forwarded using radius R to the service ID (IPv6 address) indicated in the data packet header. - Forward.pkt.end. 4. The border router executes the first instruction on the list. 5. The router receives the semantic data packet and starts execution from the first instruction. The following actions can occur: - If the router address chain is not empty, the router removes the first (head) address from the chain and forwards the resulting data packet to the neighbor with that IP address.

[0071] If the router address chain is empty, the router broadcasts the semantic data packet until it reaches a router with a connection to the service ID or until the radius R terminates. In the former case, the router sends the payload of the semantic data packet to the border router, where that border router can be reached via the interface configured with the service ID. All routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

[0072] Two operation phases (announcement and forwarding) utilize the semantic data packet format, which is based on the IPv6 routing header defined according to the new routing type "semantic routing" and has the following fields: - Routing type: Semantic - Instruction index: The number of octets from the start of the instruction list. The initial value is set to 0, and it points to the first instruction to be executed. After an instruction is executed, the value is incremented by the number of octets of the total size of the instruction. - Remaining instructions: The remaining number of instructions. The initial value is set to the total number of instructions. After an instruction is executed, the value is decremented by 1. The minimum number is 1, which indicates the end of the instruction list has been reached. - Chain index: Used in active mode to point to the current element in the routing chain used in some instructions. - Instruction list: The list of instructions. The list can have a variable size. - Padding: Set accordingly with IETF RFC8200.

[0073] Semantic data packets are used to carry different instruction lists for different phases of the protocol:

[0074] The actions to be performed for each type of routing instruction are described in this section.

[0075] Table 1 gives an overview of the names and parameters of each instruction.

[0076] Description of the Drawings

[0077] Figure 1 A flowchart of the method is shown;

[0078] Figure 2 Semantic routing general signaling is shown; and

[0079] Figure 3 The format of the semantic data packet is shown. Detailed Description of the Invention

[0080] The illustrations in the drawings are schematic and not to scale. If the same reference numerals are used in the following description of the drawings in different drawings, they represent the same or similar elements. However, the same or similar elements may also be represented by different reference numerals.

[0081] According to one aspect, a semantic routing method 100 for a time-varying network is provided, wherein the method 100 is configured to provide congestion-aware source-based routing to satellites (preferably a LEO constellation) using a distributed name resolution system, the distributed name resolution system including - a plurality of routers, - a plurality of border routers, - service providers,

[0082] wherein, the method 100 includes an advertisement phase, and the advertisement phase includes the following steps: 101 Create a border router order list of the plurality of border routers in ascending order of the distance from the current border router; 102 The current border router creates a list of semantic data packets with multiple instruction pairs of the following types: Forward the semantic data packet (Forward.pkt.areaID) to a specific geographical area with the geographical location ID of the geographical area of the destination border router; Broadcast (Forward.pkt.servID) the semantic data packet to a specific service ID with the IP addresses of the plurality of border routers having a radius of R; End (Forward.pkt.end) the execution instruction; 103 The current border router executes the first instruction on the list; 104 The plurality of routers receive the semantic data packet and start executing from the first instruction, wherein: - If the router is not in the geographical area of the destination border router, further forward the semantic data packet to an adjacent router; or - If the router is in the geographical area of the destination border router, it broadcasts the semantic packet within that geographical area until it reaches a router that has a connection to the destination border router or a termination radius R, where the router with a connection to the destination border router or a termination radius R sends the payload of the semantic packet to the current border router, and the router with a connection to the destination border router or a termination radius R executes the following instructions in the semantic packet, and all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic packet;

[0083] where the method 100 further includes a forwarding phase, where the information previously exchanged between the multiple border routers is used to forward packets, and the forwarding phase is configured to be executed in an active mode or a response mode, where: In the active mode, the multiple border routers trigger semantic packets with path discovery messages to a specific service by themselves in order to identify the most suitable path, where the information about the identified path is placed in the local routing table and used as a label in future semantic packets, thus allowing for faster forwarding within a time-varying network, and In the response mode, the multiple border routers trigger the transmission of semantic packets to carry the packets received from the interfaces connected to the external network, where the multiple border routers create semantic packets forwarded by routers that do not store any state during this process, where the semantic packet includes a header and a payload, the header has the IP address of the border router as the source address and the IP address of the destination service, and the payload has the received packet and an extended header that allows the payload to be distributed in unicast mode, such that the method 100 operates based on geographical routing, which can adapt to network dynamics and forward traffic via a group of satellites as close as possible to the destination,

[0084] where executing the forwarding phase in the response mode (left branch) includes the following steps: 105.1 The multiple border routers receive semantic packets from the external network, 106.1 The multiple border routers use the service name carried in the received packet to check the locally stored information in order to identify the border router hosting the service, 107.1 Select a specific hosting border router based on the configured forwarding policy from the list of possible hosting border routers, 108.1 The multiple border routers create semantic packets with the following routing instructions in the extended header: - Forward the data packet (Forward.pkt.areaID) to a specific geographical area with the geographical location ID of the geographical area having the destination border router; - Broadcast the data packet (Forward.pkt.servID) to a specific service ID, where the data packet is forwarded using a radius R to the service ID (IPv6 address) indicated in the data packet header; - End (Forward.pkt.end) the execution instruction. 109.1 The first instruction on the list is executed by the plurality of border routers. 110.1 The semantic data packet is received by the plurality of border routers and execution starts from the first instruction, where: - If the router is not in the geographical area of the destination border router, forward the semantic data packet to an adjacent router that is geographically closer to the destination and least congested; or - If the router is in the geographical area of the destination border router, broadcast the semantic data packet within the geographical area until it reaches a router having a connection to the service ID indicated in the data packet header or until the radius R terminates, where the router sends the payload of the semantic data packet to the border router, and all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

[0085] Performing the forwarding phase in the active mode (right branch) includes the following steps: 105.2 One of the locally installed services is selected by the plurality of border routers, 106.2 The plurality of border routers create a semantic data packet having the following routing instructions in the extension header: - Collect (Discover.path.to.areaID) information about the routers in the path towards a specific geographical area with the geographical location ID of the geographical area having the destination border router; - Create (Create.reverse.pkt) a new semantic data packet; - End (Forward.pkt.end) the execution instruction; 107.2 The first instruction on the list is executed by the plurality of border routers, 108.2 The semantic data packet is received by the plurality of border routers and execution starts from the first instruction, where: - If the router is not in the geographical area of the destination border router, the router: i. Identifies an adjacent router that is geographically closer to the destination and least congested; ii. Add the IDs of the selected adjacent nodes to the head of the router address chain in the data packet payload; iii. Forward the semantic data packet to the selected adjacent router; Or - If the router is in the geographical area of the destination border router, the router adds its ID to the head of the router address chain and executes the next instruction. 109.2 The destination router creates a new semantic data packet with the current router's IP address as the source address, the service ID carried in the previous data packet as the destination address, and the chain index in the data packet header as 1, including the following instructions: - Forward (Forward.pkt.chainID) the semantic data packet to a specific geographical area with the router address chain collected from the received semantic data packet; - Store (Stores.chain.servID) information about the received router chain; - End (Forward.pkt.end) the execution of the instruction. 110.2 The destination router executes the first instruction. 111.2 The multiple border routers execute the first instruction on the list, forward the semantic data packet to the router with the first IP address indicated in the instruction, and increment the chain index by 1. 112.2 The multiple routers that receive a semantic data packet with a chain index greater than the size of the router address chain execute the second instruction and store the router address chain associated with the service, the ID of which is indicated as the destination IP in the data packet header.

[0086] For all services with non-empty router address chains, the border router will use the following process to forward data packets: 113 The border router receives a data packet from an external network; 114 The border router uses the service name carried in the received data packet to check the locally stored information to identify the router address chain associated with the service; 115 The border router creates a semantic data packet with a header and the following routing instructions, where the header has the border router's IP address as the source address and the service ID of the selected service as the destination address, and the routing instructions include: - Forward (Forward.pkt.chainID) the data packet via a set of known routers, where the router address chain is locally stored for the received service name; - Broadcast semantic packets towards a specific service ID (Foward.pkt.servID), where the packets are forwarded using a radius R to the service ID (IPv6 address) indicated in the data packet header; - End (Forward.pkt.end) execution instruction; 116 The first instruction on the list is executed by the border router; 117 The semantic packets are received by the multiple routers and execution starts from the first instruction, where, if the router address chain is not empty, the router removes the first address from the router address chain and forwards the resulting packet to the adjacent router with that IP address, where, if the router address chain is empty, the router broadcasts the semantic packets until it reaches a router with a connection to the service ID or until the radius R terminates, where the router sends the payload of the semantic packet to the border router that can be reached via the interface configured with the service ID, and where all routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic packet.

[0087] Figure 2 Illustrates the general signaling for semantic routing. It shows the packet exchange process that occurs between border routers and passes through a selected set of routers in order to implement the proposed semantic routing protocol. It can be seen that the proposed semantic routing protocol covers the advertisement phase and the forwarding phase. In the latter case, as described above, the forwarding phase can follow a reactive behavior or a proactive behavior.

[0088] Figure 3 Illustrates the format of the semantic packet. Two operation phases (advertisement and forwarding) utilize the semantic packet format, which is based on an IPv6 routing header defined according to the new routing type "semantic routing", which has the following fields: - Routing type: semantic

[0089] - Instruction index: The number of octets from the start of the instruction list. The initial value is set to 0, and it points to the first instruction to be executed. After executing an instruction, the value is incremented by the number of octets of the total size of the instruction. - Remaining instructions: The remaining number of instructions. The initial value is set to the total number of instructions. After executing one instruction, the value is decremented by 1. The minimum number is 1, which indicates the end of the instruction list has been reached. - Chain index: Used in proactive mode to point to the current element in the routing chain used in some instructions. - Instruction list: The list of instructions. The list can have a variable size. - Filling: Set accordingly with IETF RFC8200.

[0090] Compared with other methods aimed at routing traffic on LEO satellite constellations, the present invention has the following benefits: - Operates based on semantics such as geographical location, IP address, service name, information about congestion, etc. - Has an embedded distributed system for resolving service names into semantic addresses. - Uses source-based routing, enabling the satellite to implement a simple routing engine. - Operates based on geographical routing, which can adapt to network dynamics and forward traffic via a group of satellites as close as possible to the destination. - Can route traffic around congested satellites if congestion is detected. - Can support multicast traffic by enabling semantic addresses to include multiple destinations.

Claims

1. A semantic routing method (100) for a time-varying network, wherein, The method (100) is configured to provide congestion-aware source-based routing to satellites, preferably a LEO constellation, using a distributed name resolution system, the distributed name resolution system comprising - a plurality of routers, - a plurality of border routers, and - service providers, wherein the method (100) includes an advertisement phase, the advertisement phase including the following steps: (101) Create a border router order list of the plurality of border routers in ascending order of distance from the current border router; (102) The current border router creates a semantic data packet of a list of multiple instruction pairs of the following types: Forward the semantic data packet (Forward.pkt.areaID) to a specific geographical area with the geographical location ID of the geographical area of the destination border router; Broadcast (Forward.pkt.servID) the semantic data packet to a specific service ID with the IP addresses of the plurality of border routers having a radius of R; End (Forward.pkt.end) execution instruction; (103) The current border router executes the first instruction on the list; (104) The plurality of routers receive the semantic data packet and start execution from the first instruction, wherein: - If the router is not in the geographical area of the destination border router, further forward the semantic data packet to an adjacent router; or - If the router is in the geographical area of the destination border router, broadcast the semantic data packet within the geographical area until it reaches a router having a connection to or a termination radius R from the destination border router, wherein the router having a connection to or a termination radius R from the destination border router sends the payload of the semantic data packet to the current border router, and the router having a connection to or a termination radius R from the destination border router executes the following instruction in the semantic data packet, wherein all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet; wherein the method (100) further includes a forwarding phase, wherein information previously exchanged between the plurality of border routers is used to forward data packets, wherein the forwarding phase is configured to be executed in an active mode or a response mode, wherein: In the active mode, the plurality of border routers trigger semantic data packets with path discovery messages to a specific service by themselves in order to identify the most suitable path, wherein information about the identified path is placed in the local routing table and used as a label in future semantic data packets, thereby allowing faster forwarding within the time-varying network, and In the response mode, the plurality of border routers trigger the transmission of semantic packets to carry the packets received from the interfaces connected to the external network, wherein the plurality of border routers create semantic packets forwarded by routers that do not store any state during this process, wherein the semantic packets include a header and a payload, wherein the header has the IP address of the border router as the source address and the IP address of the destination service, and the payload has the received packet and an extension header, and the extension header allows the payload to be distributed in unicast mode. The method (100) is made to operate based on geographic routing, which can adapt to network dynamics and forward traffic via a set of satellites as close as possible to the destination.

2. The method (100) according to claim 1, wherein, Performing the forwarding phase in the response mode includes the following steps: (105.1) Receive semantic packets from the external network by the plurality of border routers.

3. The method (100) according to claim 2, further comprising the following steps: (106.1) The plurality of border routers use the service name carried in the received packet to check the locally stored information to identify the border router hosting the service.

4. The method (100) according to claim 3, further comprising the following steps: (107.1) Select a specific hosting border router based on the configured forwarding policy from the list of possible hosting border routers.

5. The method (100) according to claim 4, further comprising the following steps: (108.1) The plurality of border routers create semantic packets having the following routing instructions in the extension header: - Forward the packet (Forward.pkt.areaID) to a specific geographical area having the geographical location ID of the geographical area of the destination border router; - Broadcast (Forward.pkt.servID) the packet to a specific service ID, wherein the packet is forwarded to the service ID (IPv6 address) indicated in the data packet header using the radius R; - End (Forward.pkt.end) the execution instruction. (109.1) The plurality of border routers execute the first instruction on the list.

6. The method (100) according to claim 5, further comprising the following steps: (110.1) The plurality of border routers receive the semantic packet and start executing from the first instruction, wherein: - If the router is not in the geographical area of the destination border router, forward the semantic packet to an adjacent router that is geographically closer to the destination and least congested; or - If the router is in the geographical area of the destination border router, broadcast the semantic data packet within the geographical area until it reaches a router with a connection to the service ID indicated in the data packet header or until the radius R terminates, where the router sends the payload of the semantic data packet to the border router, and all other routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

7. The method (100) according to claim 1, wherein, Performing the forwarding phase in the active mode includes the following steps: (105.2) Selecting one of the locally installed services by the plurality of border routers.

8. The method (100) according to claim 7, further comprising the following steps: (106.2) Creating, by the plurality of border routers, a semantic data packet having the following routing instructions in the extension header: - Collect (Discover.path.to.areaID) information about routers in the path to a specific geographical area with a geographical location ID towards the geographical area of the destination border router; - Create (Create.reverse.pkt) a new semantic data packet; - End (Forward.pkt.end) the execution instruction; (107.2) Executing, by the plurality of border routers, the first instruction on the list.

9. The method (100) according to claim 8, further comprising the following steps: (108.2) Receiving, by the plurality of border routers, the semantic data packet and starting execution from the first instruction, where: - If the router is not in the geographical area of the destination border router, the router: i. Identifies an adjacent router that is geographically closer to the destination and least congested; ii. Adds the ID of the selected adjacent node to the head of the router address chain in the payload of the data packet; iii. Forwards the semantic data packet to the selected adjacent router; Or - If the router is in the geographical area of the destination border router, the router adds its ID to the head of the router address chain and executes the next instruction.

10. The method (100) according to claim 9, further comprising the following steps: (109.2) Creating, by the destination router, a new semantic data packet with the current router's IP address as the source address, the service ID carried in the previous data packet as the destination address, and a chain index of 1 in the data packet header, including the following instructions: - Forward (Forward.pkt.chainID) the semantic data packet to a specific geographical area with the router address chain collected from the received semantic data packet; - Store (Stores.chain.servID) information about the received router chain; - End (Forward.pkt.end) the execution instruction.

11. The method (100) according to claim 10, further comprising the following steps: (110.2) Execute a first instruction by the destination router.

12. The method (100) according to claim 11, further comprising the steps of: (111.2) Execute the first instruction on the list by the plurality of border routers, forward the semantic data packet to the router with the first IP address indicated in the instruction, and increment the chain index by 1.

13. The method (100) according to claim 12, further comprising the steps of: (112.2) Execute a second instruction by the plurality of routers that receive a semantic data packet with a chain index greater than the size of the router address chain, and store the router address chain associated with the service, the ID of which is indicated as the destination IP in the data packet header.

14. The method (100) according to any one of claims 7 - 13, wherein, For all services with non-empty router address chains, the border routers will use the following procedure to forward data packets: (113) Receive a data packet from an external network by the border router; (114) Check the locally stored information using the service name carried in the received data packet by the border router to identify the router address chain associated with the service; (115) Create a semantic data packet with a header and the following routing instructions by the border router, where the header has the IP address of the border router as the source address and the service ID of the selected service as the destination address, and the routing instructions include: - Forward (Forward.pkt.chainID) the data packet via a set of known routers, where the router address chain is locally stored for the received service name; - Broadcast (Foward.pkt.servID) the semantic data packet towards a specific service ID, where the data packet is forwarded using a radius R to the service ID (IPv6 address) indicated in the data packet header; - End (Forward.pkt.end) execution instruction; (116) Execute the first instruction on the list by the border router; (117) Receive the semantic data packet by the plurality of routers and start execution from the first instruction, where, if the router address chain is not empty, the router removes the first address from the router address chain and forwards the resulting data packet to the adjacent router with that IP address.

15. The method (100) according to claim 14, wherein, If the router address chain is empty, the router broadcasts the semantic data packet until it reaches a router with a connection to the service ID or until the radius R terminates, where the router sends the payload of the semantic data packet to the border router, where the border router is reachable via an interface configured with the service ID, and where all routers within the geographical area execute the last instruction (Forward.pkt.end) carried in the semantic data packet.

Images