Node 6 routes with the same BAP address. The usage of both BAP address and BAP path ID is somewhat redundant and is indicative of the difficulties with the 3GPP decision making process. Nevertheless, it has the benefit of flexibility, which is elaborated upon below. The IAB node holds a routing table with the next-hop link for each BAP routing ID. When a BAP packet has reached its final destination, it is passed to the upper layers (i.e. IP layer and above). The combination of BAP address and BAP path ID enables source-based as well as local route selection. One example is shown in Figure 5.2.9, where the source of the packet (e.g. the IAB donor) can select between two routes, P1 and P2, that lead to the same destination (node 6 with BAP address = A6). The source node can select one of the routes by enclosing the corresponding BAP path ID together with the BAP address into the packet header. In case node 1, where both routes bifurcate, observes radio link failure on the source-selected route (path P2), it can overwrite the source's decision and send the packet on the alternative route (path P1), which it finds based on the BAP address (address A6). The BAP header information is configured by the IAB donor CU to ensure topology-wide uniqueness of BAP routing IDs and BAP addresses. The routing table entries on the IAB nodes could either be configured via a routing protocol or by a central controller, such as the IAB donor CU, following SDN principles. Routing protocols can be designed to scale to large topologies, and they do not require a central control mechanism. The route selection rules applied by these protocols, however, need to be standardized SO that interoperability is guaranteed. SDN-based route configuration has limited scalability and requires a controller function. For IAB, 3GPP decided in favor of an SDN-based mechanism since the IAB donor CU was available for central control. Also, scalability was not considered critical as topolo- gies underneath the IAB donor were expected to have at most a few te