Handover Scenario Signaling

In document Interoperabilidade e mobilidade na internet do futuro (Page 125-129)

4.2 Supporting Mobility in Evolutionary SDN-based Architecture

4.2.3 Handover Scenario Signaling

The link layer abstraction enabled by IEEE 802.21 allows this framework to be decoupled from link related aspects. As such, the presented signaling in this section can be deployed over different technologies (e.g. WiFi, WiMAX and mobile).

The proposed framework approaches the handover procedure in three steps: (i) handover preparation; (ii) handover commit; and (iii) handover complete. As the name indicates, the first step is related with the preparation procedures before the occurrence of the handover itself, which includes checking the available resources in the possible handover candidates. In the second step, the MN commits to handover to the chosen PoA, with resources in the handover target (and eventually, other entities of the network) being prepared to accommodate the MN. In addition, the handover procedure itself is executed at the end of this step. Finally, the last step is related with conclusion aspects, such as the release of resources from the old PoA.

The initiation of each step of the handover procedure could be triggered by the MN or the network (by both the Controller/PoS or the PoA). The signaling presented in the following subsections encompasses all possible scenarios. In the dashed boxes, the signaling specific to each case is represented, where A, B and C identify if the trigger is initiated by the MN, Controller/PoS and PoA respectively. The remaining signaling is common to all the cases.

4.2.3.1 Handover Preparation

The proposed framework is flexible to allow different entities to trigger the initiation of the handover procedures. The controlling entity, which by monitoring the overall state of the network at each instant, can decide to handover specific flows or MNs to another PoA due to e.g. load-balancing purposes. Additionally, the MNs can request the initiation of the handover procedure if e.g. better connectivity conditions are found. The PoA can also trigger the initiation of the handover procedure, although indirectly, by sending events to the PoS indicating that it is e.g. overloaded. The signaling for each case is illustrated in Figure 4.5.

Figure 4.5: Handover Preparation Signaling using the proposed IEEE 802.21-enabled OpenFlow Framework

While on the move, the MN can detect new PoAs in its surroundings, triggering an event to its mobility manager notifying about the detected PoAs. The mobility manager in the MN can then decide based on several factors (e.g., signal strength of the PoAs under its range) sending a MIH MN HO Candidate Query.request (message A1.1 in Figure 4.5) towards its PoS, indicating the potential PoAs that it is interested in moving to. By doing so, the MN is triggering a mobile-initiated handover.

In turn, the mobility entity in the PoS can trigger a network-initiated handover by sending a MIH Net HO Candidate Query.request towards the MN with a list suggesting potential PoAs for the MN handover to (message B1.1 in Figure 4.5). The MN responds with a MIH Net HO Candidate Query.response (message B1.2 in Figure 4.5),

4.2. Supporting Mobility in Evolutionary SDN-based Architecture 103 acknowledging not only the handover initiation, but also informing the PoS about the preferred PoAs.

The third possibility is the initiation of the handover by the PoA. For example, the PoA can trigger an event to the PoS indicating that one of its interfaces is going down (e.g., due to malfunction) (message C1.1 in Figure 4.5). Upon the reception of such event, the PoS triggers the handover of all the MNs connected to that PoA using the same signaling as describe before for the network-initiated handover (message C1.2 and C1.3 in Figure 4.5). In this case, the PoS can handle the handover of each MN individually, or handle it as a single handover of a group of MNs [27, 6, 5].

Independently of the chosen approach, at this stage, the PoS holds information regarding the potential candidate handover PoAs. As such, for each of these PoAs, the PoS checks available resources (messages 2 and 3 in Figure 4.5) to verify if they can accommodate the attachment of the MN.

Finally, for the mobile-initiated handover use case, the PoS returns a list of potential candidate PoAs to the MN, sorted from the most preferred to the least preferred by sending a MIH MN HO Candidate Query.response (message A4.1 in Figure 4.5).

4.2.3.2 Handover Commit

The handover commit step can be initiated by either the MN or the PoS (as depicted in Figure 4.6).

Whenever this process is initiated by the MN, it starts by notifying the PoS about the selected PoA by sending a MIH MN HO Commit.request to the PoS (message A1.1 in Figure 4.6). If initiated by the PoS, the MN’s decision corresponds to the most preferred PoA indicated by the MN in the handover preparation step (message A4.1 in Figure 4.5).

Upon the reception of the MN’s decision, the PoS reserves the resources at the target PoA to accommodate the incoming MN (messages 2 in Figure 4.6). When the PoA acknowledges the PoS request with a sucessful status (message 3 in Figure 4.6), the PoS proceeds to the reconfiguration of the network in order to make ongoing sessions of the MN reach the candidate PoA. For that, using OpenFlow protocol (i.e., acting as the OpenFlow Controller), it issues a OFPT FLOW MOD (message 4 in Figure 4.6) message towards the PoA as well as to other OpenFlow switches under its domain that require an update of the forwarding tables. An OFPT BARRIER REQUEST message (message 5 in Figure 4.6) is sent after the OFPT FLOW MOD message, so that when the corresponding response (message 6 in Figure 4.6) is received, the PoS knows that the forwarding rules were already configured. At this point, the path to the candidate PoA is established before the handover procedure occurs, aiming to reduce the time

Figure 4.6: Handover Commit Signaling using the proposed IEEE 802.21-enabled OpenFlow Framework

required to restore ongoing sessions after the handover itself. Nevertheless, the path to the old PoA is temporarily kept in order to maintain the ongoing sessions before the handover occurs.

At this stage, the selected candidate PoA is ready to accommodate the MN and, therefore, the PoS instructs the MN to initiate the L2 handover procedure to the candidate PoA. If the handover commit step was initiated by the MN, the PoS sends an MIH MN HO Commit.response message to the MN (message A7.1 in Figure 4.6). Otherwise, the PoS notifies the MN about the target PoA via MIH Net HO Commit.request message (message B/C7.1 in Figure 4.6), which, in turn, acknowledges its reception by sending an MIH Net HO Commit.response message (message B/C7.2 in Figure 4.6) to the PoS.

In the end of handover commit step, the MN executes the L2 handover to the selected candidate PoA.

4.2.3.3 Handover Complete

The following step is the handover completion, in which resources allocated to the MN in its old locations are released. The signaling presented in Figure 4.7 is the same

4.2. Supporting Mobility in Evolutionary SDN-based Architecture 105 independently of which entity initiated the handover procedure.

Figure 4.7: Handover Complete Signaling using the proposed IEEE 802.21-enabled OpenFlow Framework

Upon the connection to the candidate PoA, an event is generated either on the MN (message 1 in Figure 4.7) and on the candidate PoA (message 2 in Figure 4.7). The MN, detecting that the connection to the candidate PoA is already established, informs the PoS by sending an MIH MN HO Complete.request (message 3 in Figure 4.7) which, in turn, initiates the procedures to release the resources allocated to the MN in what concerns its old location. Thus, the PoS triggers the OpenFlow procedures to clear routing information related with the MN from the old PoA, by updating the flow tables of both the old PoA and intermediate switches (message 4 in Figure 4.7). As in the previous step, OFPT BARRIER REQUEST messages (message 5 in Figure 4.7) are sent after the OFPT FLOW MOD so that whenever it receives the corresponding OFPT BARRIER REPLY messages (message 6 in Figure 4.7) it knows that the flow tables have been updated. In parallel, the PoS also notifies the old PoA to release the resources allocated to the MN (messages 7 and 8 in Figure 4.7). Finally, the PoS acknowledges the MN that the handover procedure on the network side is completed by sending a MIH MN HO Complete.response message (message 9 in Figure 4.7).

In document Interoperabilidade e mobilidade na internet do futuro (Page 125-129)