User Connection Failure

As the architecture proposed in this work addresses dynamic heterogeneous network scenarios, it is essential that the whole network react accordingly to changes. This way, the implementation made must predict cases as connection failures in the access networks for instance, and adapt to these changes providing a reliable and seamless multiparty content delivery to the users by maintaining them connected ensuring the respective QoS requirements.

Thus, it was implemented an approach to detect a user connection disruption, which can occur due to an access point failure or if the user is moving away from the AP. Hence, it is possible to properly react to the failure by searching a new AP that can hold the aected trac, ensuring a quality service and a new core path to eciently distribute the data ow.

This mechanism will release the aected connection and search for an alternative one to accommodate the user. It appears to be an easy procedure, but it is not as simple as it seems. There are parameters that may require dierent ways of perform the release.

To make the release of the old connection it is necessary to examine if there are more users receiving the same multiparty content through the same access point. If this is true and the client is receiving the trac through multicast technology, the envisioned user only has to leave the multicast group, but if it is receiving through unicast, the connection between the AP and the user must be cancelled and removed. On the other hand, if the aected user is the only one receiving the data through the AP, it might be necessary to release the entire path in the core network that is being used to transport the multiparty content.

As the connection disruption is implemented through code, it was implemented a method to inform NUM about the failure immediately before the user loses connectivity. So, initially the user sends a message to NUM notifying it about the problem. This message only carries the addresses of the user itself, the AP in which he was connected and a ag indicating whether this user has or not multicast capabilities. In the beginning NUM will determine which is the ow ID of the trac that was being received by the aected user. To do this, it is called the function search_d_userAP, receiving as arguments the user and AP addresses. This function nds in the list userPosition the ow ID received by the user before the disconnection. Besides this, it is also needed to know how many of the users connected to the AP are receiving the same data of the envisioned user. Depending on this number, dierent actions are performed by the algorithm. To know this, the function search_conection_userAP is called.

If there are more users beyond the one disconnected, and the ag received in the message indicates that the user was receiving through multicast, it is executed an MIRA command to leave the group. But if the ag implies that the user was receiving through unicast, the connection is deleted. In both cases, it is removed the correspondent entry from the list userPosition using the function remove_conection_userAP.

However, if there are no more users consuming the same content, all the path, including the core network path and the access network connection, will be released. In order to discover the entire path that was used to connect the user, it was used the function search_path_dPaths. Finally, the release itself is performed by the function treat_releaseMTO. After releasing the resources allocated in the core network, NUM must refresh the structures that hold link and available paths bandwidth in order to maintain the current network state updated. This is done by calling the functions

updateBandwidthLinks_release and updateBandwidthPaths_release. It is also removed from the structure pathsFid the path correspondent to the release performed through the function remove_item_dPaths that receives as arguments the ow ID and the old AP address.

After releasing the adequate connections and update the relevant structures, it is discovered the session ID aected by this failure, using the function search_sessID_dPaths.

At this time NUM sends a message to CB with the session ID, user address and ow ID, so a new connection can be established. Since this point, the process is just equal to the session setup procedure. So, the system will try to accommodate this user in a dierent access network that can support its QoS requirements.

To completely understand this process, all the steps performed by this method are described in the Figure 22.

Warning Move Are there more users using this path? Release the entire path Update the related structures

User leave the multicast group No

Yes

NUM interacts with CB to requesting contexts in order

to start the Session Establishment process

User sends request to

move

Figure 22: User move process.

Figure 23 presents the messages exchange needed to successfully implement this feature.

USER NUM MTO CB

Warning Move

Request Best Access Network Connection

Return Best Access Network Connection Configure MTO parameters to leave a group or release a path

- Configure MTO tree connections - Stop data delivery

- Selects the best communication path to connect the user - Allocates IP multicast address (if applicable)

Configure MTO parameters to join a group or reserve a path

- Allocates communications port - Configure MTO tree connections - Start data delivery

Contexts Infomation

Triggers the Session Setup while Requests Context

Figure 23: High-Level Message Sequence Chart for Move Warning.