Enhancing Resource Control in Context-Sensitive Heterogeneous Networks

J. Castillo1, 2, E. Cruz1, A. Neto1,3 , S. Sargento3, E. Cerqueira4

Teleinformatics Engineering, Federal University of Cear, Fortaleza-CE, Brazil 2 Computer Engineering, University of Corua, Corua, Spain 3 Institute of Telecommunications, University of Aveiro, Aveiro, Portugal 4 Computer Engineering, Federal University of Para (UFPA), Belm-PA, Brazil jose.castillo@udc.es, elifranioalves@gmail.com, augusto.deti@ufc.br, susana@ua.pt, cerqueira@ufpa.br
Abstract Mobile users are increasingly demanding multimedia content created specifically or at least tailored to cater for their needs and preferences. In this scope, context-sensitive networking embeds promising technologies for allowing the design of personalized multi-user service applications. The Context Casting (C-CAST) project designed a context-sensitive network architecture to support personalized multi-user sessions with Quality of Service (QoS) guaranteed towards multiple users simultaneously, and in their wireless technologies. The QoScontrol mechanism of legacy C-CAST introduces performance penalties, since the signalling approach adopted is per-flow driven, meaning that the signalling load exponentially increases with the number of flow admissions. This paper proposes the Advanced C-CAST, which re-architects the legacy C-CAST system for improved performance capabilities. To achieve this, the legacy C-CAST was extended to integrate over-provisioning of per-class bandwidth and overlay trees, seeking to drastically reduce the amount of signalling load throughout the system. The evaluation of Advanced C-CAST was carried out through simulations, demonstrating its benefits against Legacy C-CAST by optimizing overall signalling load while keeping users with best quality perception in terms of delay and jitter experience.
1

technologies [2]. To achieve this, the network systems should embed innovative mechanisms deploying the combined control of QoS and multi-user capabilities [3] to enhance the bandwidth use and to ensure low rates of delivery costs (e.g., latency, propagation delay, jitter and packet loss). The Context Casting (C-CAST) project [4] was carried out motivated by the inefficiency of current Internet architecture to support the requirements described above. The C-CAST project developed an advanced context-sensitive architecture supporting end-to-end context creation, reasoning and a multiuser distribution framework to address three functional issues: (i) the development of context and session group management enablers for context representation, context assisted group management and context reasoning; (ii) the definition of a framework to collect sensor data, distribute context information and manage context aware multiparty and multicast transport efficiently; (iii) and the development of mechanisms for autonomous context-driven content creation, adaptation and media delivery. In order to deal with the functional issues described above, the C-CAST system architecture (denoted in this paper as Legacy C-CAST) was designed embedding innovative mechanisms beyond Internet standards. In the transport field, data is delivered along Abstract Multi-Party Trees (AMT), which are overlay structures with network segments involving different technologies (i.e., unicast and multicast) connecting senders and multi-users of different network technologies (denoted as multi-party). In what concerns the context-driven network resource control (the focal point of this paper), the Legacy C-CAST system adopted a hierarchical architecture of Overlay Nodes (ON) and IP Transport (IPT) capabilities [5]. The ONs dynamically control the resources in each AMT, which are enforced in each node through the IPTs that control the approach developed in [6]. This mechanism can be distinguished from other related proposals (including IP standards and third-partners solutions) by allowing the dynamic enforcement of per-class bandwidth reservations and IP multicast trees in a coupled way [7]. Besides its superior performance among its related work, the signalling approach used for interaction between ONs and IPTs is only triggered when changes in the link reservations need to be updated for a specific class. This is performed through coordination between architectural elements (ONs).

Keywords-component: Context Sensitive Networks; Resource Overprovisioning; Quality of Service Control; Multi-user Sessions. I. INTRODUCTION Increasingly, users want to view and share multimedia content created specifically or at least tailored to cater for their needs and preferences. With this in mind, IP-based service providers are significantly investing in designing personalized service applications for multiple users simultaneously (multiuser) increasing their income and attracting a larger share of the multimedia market (e.g., IPTV, push media, immersive media, etc.). However, the task of designing personalized multi-user service applications is very hard and challenging. On the one hand, personalized information requires content interpretation and modelling (recognizing patterns in users behaviour and capabilities), suitable content retrieval and filtering, and filtered content adaptation to the usage environment [1]. Unfortunately, none of the standards specify how information should be used or filtered according to user requirements. On the another hand, the network system must fulfil the rigorous Quality of Service (QoS) requirements of multimedia multi-user content delivery to keep mobile users with acceptable quality perception over the time, and in their

The integrated control of QoS (per-class over-reservations) and connectivity (IP multicast aggregation trees) resources, following the over-provisioning strategy, is supported by the Multi-user Aggregate Resource Allocation (MARA) [8] to alleviate the performance limitations of per-flow driven signalling approaches in networks with only one ingress point. The main purpose of MARA consists in bootstrapping both QoS and connectivity resources at the network boot up. As a result, the signalling events are only required at the system boot up and to re-adjust the QoS resources. In the latter case, the QoS resources are re-adjusted when it is detected that the admission of a flow belonging to a demanding session (session-flow) will exhaust the current over-reservation of the class in which this flow is mapped. The outcomes of MARAs over-provisioning centric strategy demonstrated that it makes a drastic impact in optimizing the signalling load of per-flow driven solutions. As a result, the overall system performance may be optimized, mainly in terms of processing/state overhead and energy consumption, as well improving the bandwidth use. As a cascade effect, the quality perceived by users can also be improved by allowing the optimization of the delivery costs (low rates of propagation delay, jitter and packet loss). MARA only maintains information respecting the bottlenecks QoS capabilities of existing multicast aggregation trees, since it assumes that none of the existing paths correlates each other (i.e., they dont share network segments). This is justified by the fact that MARA was designed for networks with a single ingress router, thus drastically reducing its opportunity in large-scale network providers that mainly deploy multiple ingress routers. In view of this, we claim that adopting QoS and connectivity over-provisioning centric capabilities would benefit Legacy C-CAST system to establish personalized multiparty sessions while improving the system scalability. For this reason, this paper proposes a new C-CAST architecture, denoted as Advanced C-CAST, which redesigns the Legacy CCAST architecture to deploy QoS and connectivity resource control following the over-provisioning concept. Moreover, the hierarchical scheme and its support of rich information databases, envisions to allow adopting the over-provisioning centric mechanism in networks with multiple ingress routers as expected for future Internet architectures. The results of the preliminary performance evaluation of Advanced C-CAST were analysed through simulations, demonstrating its superior benefits with regard to the legacy configuration in the network and user perspectives in terms of bandwidth use, as well as delay, jitter and loss rates [5]. This paper is structured as follows. Section II outlines the previous C-CAST architecture and its components. In Section III, the Advanced C-CAST proposal is described in greater depth. A use case is provided in Section IV, aiming at facilitating to understand how Advanced C-CAST works. The results and analysis of the preliminary performance evaluation are examined in Section V. Finally, Section VI describes the conclusion and refers to future work that might build on the outcome of this work.

II.

CONTEXT CASTING OVERVIEW

The C-CAST project was created with the purpose of promoting context-sensitive techniques orchestrated to dynamically support the delivery of multimedia content towards multiple users simultaneously. To achieve this, a context-driven system was architected with components supporting the following features: context-awareness, session management and multiparty content delivery (i.e., over heterogeneous network technologies simultaneously). The following section will provide a general overview of the CCAST system. The Context Acquisition Framework is built of several sensors distributed throughout the network, which feed a central repository named Context Broker (CB). This feature is crucial to provide the knowledge required for the development and support of personalized services, adapting contents and the way they are delivered according to the users particular context (device, preferences and surrounding environment). At the session layer, the Session Management (SM) is the entity that controls the relationship between available sessions and potential users. SM collects information to manage session events and to create the session context, which consists of sessions group members identification and QoS requirements. This paper focuses on the Context-Aware Multiparty Transport Framework of C-CAST architecture (represented in Fig. 1), which comprehends a set of elements that hierarchically provision the content delivery and network resources. The central decision entity, named Network Use Management (NUM), uses the knowledge gathered and analysed in operations such as network selection, grouping users and resource control. The second control level is undertaken by an overlay scheme, which contains a set of nodes within the network that enforce NUM decisions on network elements, such as resource reservation and multicast tree maintenance. For each multiparty session, we define an overlay multicast delivery structure denoted Abstract Multiparty Tree (AMT), one of the main innovative concepts of C-CAST. Two types of nodes are classified in a C-CAST enabled environment, Overlay Nodes (ONs) and Core Nodes (CNs).

Figure 1. C-CAST legacy scenario [5]

The ONs are at the borders of network segments with different transport technologies (i.e., unicast and IP multicast), denoted as Sub-AMTs. The ONs are the central entities of the multiparty transport paradigm, and their embedding software agents implement the Multipart Transport Overlay (MTO) entity, which is responsible for the packet transport technology translation (i.e., unicast-to-multicast and vice versa). The CNs

are compliant with the IP standard to essentially react upon resource enforcement requests and packet forwarding according to the underlying transport technology. The software agents embedding both ONs and CNs implement the Internet Protocol Transport (IPT) entity [5]. The IPT is responsible for enforcing the amount of network resources indicated by NUM (derived upon receiving a session setup request), in accordance with the underlying network mechanisms. The IPT supports scalable QoS control, efficient IP-multicast control (when applicable), fast resilience operation, and QoS mapping. The signalling messages for QoS control are mainly used to: (i) indicate the amount of network resources for local enforcement (install, remove or update) according to the Sub-AMT technologies; (ii) reply a previously requested enforcement operation; (iii) and send asynchronous alarms (link break). The hierarchical resource control of Legacy C-CAST is class-based, with IPT being triggered only when changes in the link reservations need to be updated for a specific class. The Algorithm 1 illustrates the procedures for resource allocation in a C-CAST enabled environment to setup and reconfigure personalized multiparty session. 1 [5]

A. Advanced NUM The Advanced NUM (A-NUM) is hosted in a central node, and extends the NUM entity of Legacy C-CAST to support: (i) the triggering of the Ingress ONs in order to invoke the system bootstrap function in the entire network; (ii) maintenance of the new AMT state table; and (iii) selection of the best AMT to connect a demanding session-flow without per-flow driven signalling events. When none of the available AMTs are able to accommodate a demanding session-flow, A-NUM selects another one with a greater probability of acceptance. A-NUM was architected to be compliant with the AMTs searching algorithm used in Legacy C-CAST [6]. Afterwards, A-NUM triggers the A-IPT at the referred Ingress ON to calculate the new over-reservations configuration for the referred sessionflow class, and further enforce the resources according the underlying QoS technology. As in Legacy C-CAST, the Advanced C-CAST also supports system bootstrap, session setup, resource provisioning/enforcement, setup of new proxy policy, and resilience operations. However, the way in which Advanced C-CAST deploys the above operations are totally different, in order to be compliant with MARAs overprovisioning concept. A summary of A-NUM new operations is provided in the following (Section IV provides a deeper explanation of each operation). The system bootstrapping uses the same controlled flooding approach of Legacy C-CAST. The system bootstrap is applied by A-NUM as a consequence of noticing that the underlying network topology has changed. To that, a node must directly signal A-NUM (IP address previously configured) whenever it is attached to the network, to announce that it is a new node in the system. Upon receiving the announcement message, ANUM triggers each Ingress ON to bootstrap the system (described in next sub-section B). Therefore, A-NUM deploys the system bootstrap only at the network boot up (pick load of messages) and when a new node is added in the on going system (expected in few frequencies).

Although per-class driven, this algorithm requires a perflow driven signalling approach. As stated in the literature, it is well known that mechanisms following per-flow driven signalling approaches degrade their performance exponentially with the increase of session-flow admissions. That is, the system performance degrades with the number of session setup request arrivals, since each signalling event at least triggers network processing (header inspection, queuing/de-queuing, look up operations, etc.) and state maintenance, among others. As a result, the entire system can reveal increasingly high latency and energy consumption levels, and hence degrade the users perception. These performance issues motivated the task of re-architecting the Legacy C-CAST to improve its performance capabilities, as described in the next section. III. ADVANCED C-CAST PROPOSAL The Advanced C-CAST has as main goal applying the over-provisioning concept of MARA in the Context-Aware Multiparty Transport Framework of Legacy C-CAST. In order to achieve this goal, both NUM and IPT were re-architected to cope the control of QoS (per-class over-reservations) and connectivity (AMTs) resources.

At the end of the system bootstrapping cycle, A-NUM composes the AMT state table using the same algorithm of legacy NUM. The A-NUM is also responsible to retrieve the best AMT for a demanding session-flow for its accommodation, which is similar as it is done in the legacy NUM. As the QoS resources of all AMTs follows the overprovisioning concept, A-NUM is able to admit multiple sessions as long as the over-reservation patterns are still enough. Otherwise, A-NUM requests the readjustments of current over-reservation patterns to accommodate the demanding session-flow and provision the QoS resources for future session requests without per-flow drive signalling events. B. Advanced IPT The Advanced IPT (A-IPT) entity is hosted on all routers of the network, and it is completely different from the legacy IPT to cope with the over-provisioning approach of MARA. The operations designed in A-IPT are summarized in the following (each one is also deeper explained in Section IV). At the boot up of all nodes, the A-IPT software agent sends an announcement message towards a local booked A-NUM IP address, and keeps waiting for incoming messages invoking the

system bootstrapping. Upon receiving such message, A-IPT at ingress ON initializes over-reservation patterns of each class locally configured, by applying an initialization factor (e.g., or ) in the maximum reservation thresholds of each available class (legacy IPT only sets up a reservation to admit/remove a session-flow). Afterwards, each local network interface is unicasted with a message carrying the associated IP address and current QoS conditions (i.e. per-class: over-reservations; maximum reservation thresholds; and current rates for delay, loss and jitter). It is important to emphasize that MARA only fills the bottlenecks information, whereas A-IPT provides this information of all nodes to support the presence of multiple ingress ONs. Each neighbouring CN proceeds in the same way until reaching an egress ON, which then stops the downstream flooding process and unicasts a message directly to the IP address of the A-NUM node (locally booked). In order to guarantee that only the best-paths are booked, the flooding process is stopped whenever detecting that: (i) the local downstream interface IP is already filled in the message (avoid infinite loops); (ii) the reaching node is an ingress router (we assume that each router carries information to derive if it is an ingress, core or egress node); (iii) the amount of IP addresses reached a pre-defined limit (if it is desired to limit the number of segments for each AMT). After finishing the initialization of the entire system, A-IPT on Ingress ONs keeps waiting for messages requesting to readjust the over-reservation patterns of an indicated class to accommodate a new session-flow (detailed described in subsections b and c of Section IV). With this goal in mind, A-IPT is prepared to compute new over-reservation patterns in the AMT indicated by A-NUM. If the new over-reservation pattern exceeds the pre-defined maximum reservation threshold, AIPT attempts to re-adjust the latter patterns. The main idea consists in reducing the maximum reservation patterns of others class ion order to grant the demanding class. After configuring the new patterns of maximum reservation thresholds, the A-IPT re-processes the A-NUM message, which may allow re-adjusting successfully the over-reservation patterns so that accommodating the demanding session-flow and provisioning the system for future requests without perflow driven signalings. The signalling approach used in Advanced c-cast is presented in the next. C. Signalling Approach The signalling approach adopted in Advanced C-CAST follows the Next Steps in Signalling (NSIS) [9] protocol, and is needed to orchestrate all the components. In addition to perclass QoS support, the Advanced C-CAST signalling protocol provides IP multicast information to support Source Specific Multicast (SSM) distribution trees [10]. Thus, the communication path is signalled at the system bootstrap and whenever a request triggering is received (such as an resource readjustment requisition) to provide control information related to QoS and connectivity resources. In order to provide a low complex approach, only two signalling messages are specified, namely ENFORCE and RESPONSE. The ENFORCE messages are used to invoke an operation, and RESPONSE messages mainly feedback a previous ENFORCE message. Additionally, A-IPT agents use the RESPONSE

message for announcements and asynchronous alarms to ingress routers. As depicted in Fig. 2, a header and the message body compose the messages of the Advanced CCAST signalling protocol.

Figure 2. Header and body of the Advanced C-CAST signalling protocol

The fields in the common header are: Message Type: 8 bits, when set to FALSE = 0 the field indicates an ENFORCE message, and when set to TRUE = 1 indicates a RESPONSE message; Message-specific flags: 1 bit each. A-IPT agents inspect the message-specific flags carried in the message header to determine the operation required. The message body carries fields used to support the required operations by means of operational information. The objects in the body message are: Request Identification Information (RII): It is a unique identifier, within the context of a session, which is used to associate a RESPONSE message with a previous ENFORCE message. Reserved Path (RSVPATH): It carries the list of IP addresses of the routers visited by an ENFORCE message along a communication path. Multicast Specification (MSPEC): Used only in multicast-enabled sub-AMTs. It carries the identification of the SSM tuple (i.e., source and multicast group IP addresses) or a list of them, depending on the required operation. Operational Information (INFOSPEC): It provides feedback about a deployed operation (i.e., successful or unsuccessful. QoS Specification (QSPEC): Provides QoS parameters used by A-IPT to accomplish specific operations. In the system bootstrap, each node IP is associated to a QSPEC. The list of QoS parameters includes: per-class over-reservation pattern; current rates of delay, loss and jitter; maximum reservation threshold. The QSPEC can be extended to deal with wireless technologies (out of scope of this paper). The message composition and associated operations are: ENFORCE(I), ENFORCE message with flag I set to on to trigger the system bootstrapping; ENFORCE(P), to indicate the MTO entity at an ON to setup a new proxy policy; ENFORCE(R), to trigger the resource readjustment operation;

RESPONSE(ACK), to feed back a previously associated operation, and to provide the current QoS capabilities of the referred (sub)AMT; RESPONSE(A), to report an asynchronous network event (e.g., link break and new node addition). IV. ADVANCED C-CAST USE CASE

The scenario illustrated in Fig. 3 is used to facilitate understanding how the Advanced C-CAST can be used. Note that the network system supports multiple ingress routers (this was not supported in the over-provisioning centric mechanism originally specified in [8]).

same way, and compose a REPONSE(ACK) message of each associated ENFORCE(I) message and unicasts each one towards the local booked A-NUM. When the RESPONSE(ACK) message is received by A-NUM, it stores all the information in local state tables, and the system initialization is complete. The tree filtering process is still a part of the System Bootstrapping to compose the tree state table, which is a fundamental support for the session setup. As the combinational sequence scheme can store a large number of possibilities, A-IPT uses filters to reduce the number of combinatorial sequences and prevent processing burden. With this aim in mind, it is assumed that the reliability and performance of a multicast distribution tree depends upon their shape. Based on the fact that a distribution tree demands more network resources as the branching point gets close to the root, A-IPT discards communications paths with branching points in the ingress routers and combinations with multiple paths converging into the same router. A. Session setup This process is started whenever A-NUM receives a session setup request message, providing the information about which users want to receive the specified flows in a certain session. When A-NUM receives this information, it sends a message to the context broker requesting the context of the users and flows involved in this session. After the response from the context broker, A-NUM has all information needed to decide the best way to deliver the traffic flows to the users. Since each session request can include several users that want to receive one or more flows, the algorithm is executed for all of them, one at a time. Regarding each user, the algorithm treats each flows requested separately. The first action carried out is to search for the Access Point that can provide the best connection to the user. This selection is based on QoS values and on the characteristics of the main elements of the network (i.e., users preference, presence of multicast, bandwidth available, and current rates of delay and loss). After retrieving the AP in which the user will be connected, it is necessary to decide the best-suited path in the core network in order to maintain the established QoS parameters of the multiparty content delivery. The algorithm starts by searching in the internal structures of A-NUM to determine whether there is already a path that is being used for the specified flow from the traffic source of the chosen AP. 1) Successful If in effect there is a path being used for the specified session-flow from the source of traffic of the chosen AP, it is only necessary to join the user to the multicast group of the traffic. However, even if this entire path does not exist, but there are paths from the same source to others APs being used, they might be used as a basis for expanding the AMT to the correct AP. Hence, if any of these paths contain interior ONs, it can be used from the source to one of these interior ONs. As a result, it is only necessary to discover another sub-path from this ON to the correct AP. All the possible conjugations of sub-paths have to be analysed and compared with each other

Figure 3. Communications Scenarios of IPT-A

Whenever a node is turned on, the local A-IPT agent unicasts a RESPONSE(A) message to A-NUM. The A-NUM node sends an ENFORCE(I) message, properly filled, to all ingress nodes (ION1, ION2 and ION3 in the case). On receiving the ENFORCE(I) message, A-IPT on each ION initializes the per-class over-reservation patterns in a way compactible with the underlying QoS approach (for instance, configuring the packet scheduling priorities). Afterwards, one ENFORCE(I) message is composed for each local network interface, each of one filled in the RSVPATH object with the associated local IP and current QoS capabilities at the QSPEC object. After this, the ENFORCE(I) messages are sent over each downstream network interface accordingly (upstream is not used to avoid infinite loops). On receiving the ENFORCE(I) message, the core node (on core routers CN1, CN2, CN3 and CN4 in this case) proceed with the same approach, which means initializing local perclass over-reservation patterns, adding local network interfaces IP and associated QoS capacities to further propagate the message downstream. Before spreading the message downstream, A-IPT checks if the network interface IP is already present in the path field. If this is the case, the propagating process is cancelled; otherwise the local IP address and associated QoS capabilities are correctly added and the message is sent. After receiving the ENFORCE(I) message, the egress routers (EON1, EON2 and EON3 in the case) proceed in the

to allow the best end-to-end path to be formed. To do this, it has a control mechanism to discard the paths that do not fulfil the delay and bandwidth requirements. Thus, A-NUM discovers alternative sub-AMTs between the interior ON and the correct AP and chooses the best alternative sub-path among them, for the case, the lower delayed one with the largest amount of available bandwidth. This mechanism is repeated for all the paths that might be used as a basis for expanding the multiparty tree, which allows obtaining the best end-to-end path in the core network to connect the user. Finally, when the overall best path is found and its suitability is confirmed, the structures that hold information about the network are updated. This mechanism takes advantage of the existing paths being used in the network, optimizing then the resources, and uses the concept of Sub-AMTs, which are regarded to be as sub-networks contained between two ONs. 2) Readjustment of over reservations Considering the case of non-existence of available paths to accommodate the demanded session (if equation 1 is satisfied), a suitable path is found by simply readjusting the current over reservation patterns. ! () + !" () > !" () (1)

(!! !" ())

(4)

When none of the available paths are able to accommodate the demanded session and there is no path with probability of acceptance, because there are not enough available resources in the network, A-NUM rejects the session. 3) Setup a new policy proxy After concluding the enforcement of the QoS along the subAMT of the selected AMT (ION3-to-CON4 path), the proxy policies in the MTO at the ION3 must set so that allowing the traffic from the source to cross the sub-AMT ION3-to-CON4 in its technology. The same must be done in the next subAMT towards the AP (e.g., CON4-to-EON3) in order to allow delivering the session-flow in the entire AMT. To that, ANUM trigger the MTO by an ENFORCE(P) message carrying the parameters needed to implement the proxy for the multicast group. 4) Resilience When A-IPT detects that a local link is not available (link break), a RESPONSE(A) message is composed and sent towards the A-NUM for resilience. Under this situation, ANUM must re-route all affected sessions (derived from the session state table) to another best path. To do this, A-NUM triggers the IONs of each session-flow as a new session setup, and A-IPT works seamlessly by enforcing the required resources. If it is not possible to enforce resources, the session-flow is finished and resources are released. V. PERFORMANCE EVALUATION

: ! () !" () !"

A-NUM selects the AMT with a greater probability of acceptance by finding the path that has the maximum unused bandwidth (equation 2), and notifies the A-IPT at the referred ingress ON, which then calculates the new over-reservations configuration (equation 3) and enforce the resources accordingly.
: !!
!! (!) !"!! (!)

!! !"

(2)

As a means of evaluating the new features introduced by the Advanced C-CAST Architecture modules and the interactions between these modules and the other network elements, a solution was implemented in Network Simulator v2 (NS-2) [11], which extends the previous legacy implementation of the C-CAST Architecture. As the work undertaken in this paper was intended to improve the legacy C-CAST modules, both architectures, Advanced C-CAST and the legacy one, were evaluated with identical scenarios and configurations concerning queue scheduling, traffic policies and links bandwidth. The topology followed in the simulation scenario is shown in Fig. 4.

!" =

(!! ! !" )

(3)

: !"

If the over-reservation patterns calculated by A-IPT are not enough to ensure a suitable path, it is necessary to make a readjustment of the maximum reservation thresholds. If with the readjustment a suitable path is found, (i.e., ! () + !" () > !! ()), A-NUM selects the path with a greater probability of acceptance by finding the path that maximizes the unused bandwidth, and notifies the A-IPT at the referred Ingress ON, which then calculates the new over-reservations configuration (by using equation 4) and enforce the resources accordingly.
Figure 4. Scenario simulation

In all the experiments, each user is considered to have as many interfaces as the number of access networks, to exhibit multi-homing capacities. This means that each user is linked to all the APs placed in the network. The core network links were configured with random values of delay, between 1ms and 2ms, and different values of bandwidth, depending on the link source node, as expected for Internet. Ingress and egress routers are configured with wired links of 7 Mb/s of bandwidth. Source, core routers and AP to egress are configured with links of 5 Mb/s. Finally, it was decided that each AP would support a total of 1 Mb of traffic, imposing a delay of 10 ms. After the creation of the links, the scheduling model of the queues is configured as well as the traffic policies. It was considered the Weighted Fair Queuing (WFQ) discipline. These simulation parameters were obtained from the Legacy C-CAST test scenarios, as in [5]Error! Reference source not found.. Afterwards, the new architecture components, A-IPT and A-NUM, are configured in the network elements and placed in any of the core networks nodes. Their placement is carried out randomly, by applying each one in a single core node. It should be noted that the nodes associated with A-NUM and CB agents still perform the packets routing like regular multicast enabled routers. On the other hand, the MTO component has to be applied to all the topology nodes, in the same way as the AIPT, to allow packets routing in the entire scheme, and an exchange of information between A-NUM and the lower network layer. Then, the bit rate of the traffic considered is defined, by configuring for each source node a Constant Bit Rate (CBR) or a Exponential (EXP) agent and configuring for each user a Null agent as well as a Loss Monitor. The bit rate of the flows is passed as an argument in the scenario file. However, in all the simulations performed the bit rate configured in each CBR agent was set to 100 kbps, while the bit rate of Exponential agents was set to 125 kbps. Moreover, each source node can accommodate several traffic flows. Later, it is associated each flow to a multicast group, as the place where this flow should send the data content. Each of these traffic flows is associated with a source node and with a multicast group. In this way, all that is needed is to specify the desired flows in each session, because A-NUM automatically matches the corresponding sources and multicast groups. Finally, even though the flows requested in the sessions are randomly chosen, it was decided that, as in the real world, the type of traffic most requested would be Best-Effort traffic. Finally, random sessions establishment requests are scheduled for NUM in order to initiate the whole selection process. It was considered that each session would be always requested by one fifth of the total users connected to the network. Moreover, it was also considered that each of these users always request two data flows. Thus, given the scenario illustrated in Fig. 4, which has five users, each one would request two data flows in each session. Another relevant factor should be pointed out: the APs are configured with one preferred class, in order to perform the sub-grouping of users. However, even if the preferred AP for a certain class is already full, the flow is allocated in a different AP, as long as it has resources to fulfil the requirements of this

class. The lower bandwidth in the core network is chosen to easily overload the core in the simulations. The signalling load that both Legacy and Advanced CCAST mechanisms introduce is measured to determine their scalability properties. The mean throughput was traced to notice the overall signalling load introduced in the legacy and new Advanced C-CAST scenario, which is shown in Fig. 5. The simulation results notice a significant reduction in the signalling load of the Advanced C-CAST proposal, in comparison with the signalling load generated in the legacy one. For this concrete simulation an improvement from 40,07 KB to 26,34 KB was shown (34,26% of reduction of signalling load). As opposed to the legacy C-CAST, there are no signalling events in the case of resource availability, and there is no request for resource-releasing, since the purpose of multiuser session is to grant the associated class with extra resources that could be used in future allocations. Moreover, Advanced C-CAST only generates an ENFORCE(R), the message used for resource readjustments, when none of the available paths are able to accommodate the demanding session.

Figure 5. Signalling load of C-CAST Architecture

Additionally, the simulation results reveal that Advanced C-CAST requires more signalling load to successfully deploy the system initialization, because additional information in the signalling messages is required for the over-provisioning mechanism. The Fig. 7 shows the mean delay behaviour over the simulation for the multi-party sessions in the Legacy and the Advanced configurations of C-CAST, in order to measure the QoS control impact in the quality perceived by users.

Figure 6. Delay over time

As it can be seen in Fig. 6, there is a significant improvement in the delay behaviour, where the mean delay is improved from 29.34 ms in legacy C-Cast to 19.97 ms (31.9% of improvement) in Advanced C-CAST. In order to enforce the results of Fig. 6, the mean jitter behaviour over the simulation time is depicted in Fig. 7.

scheme of A-NUM allowed the use of Advanced C-CAST in a multi ingress router scenario. Thus, the provisional results showed that Advanced C-CAST has the potential to deliver personalized multi-user multimedia sessions with QoS-guaranteed over the time with reduced performance impact in comparison with its legacy configuration. As future work, we will submit the Advanced C-CAST architecture in more complex scenarios, in order to really prove its convenience and real efficacy over the legacy configuration. We also intend to use others measures for benchmarking in the perspective of the network and the users. In the latter case, our goal is to integrate real 3D video trace files and use Quality of Experience (QoE) metrics for accurate analysis of the users perception. REFERENCES
[1] J. Simes, and T. Magedanz, Contextualized User-Centric Multimedia Delivery System for Next Generation Networks, Telecommunication Systems Journal, vol. 48, pp. 301-316, December 2011. [2] J. Antoniou et al., "Session and Network Support for Autonomous Context-Aware Multiparty Communications in Heterogeneous Mobile Systems", International Journal of Handheld Computing Research, vol. 1, pp. 1-24, February 2010. [3] A. Neto et al. Multiparty Session and Network Resource Control in the Context Casting (CCAST) project. Future Multimedia Networking, 2009. [4] Context Casting (C-CAST) Project, Eus ICT Framework Programme. http://www.ict-ccast.eu. Acesso em Novembro de 2011. [5] N. Coutinho, T. Condeixa, R. Valbom, S. Sargento, A. Neto, Multiparty Seamless Transport, IEEE Global Telecommunications Conference (IEEE GLOBECOM 2010), Miami, Florida (USA), December 2010. [6] N. Coutinho ; T. Condeixa ; S. Sargento ; A. Neto . Energy Efficiency as Input for Context-aware Group-based Communications. Journal of Green Engineering, vol. 1, pp. 329-353, 2011 [7] A. Neto, A. Rissato, E. Cerqueira, E. Monteiro, P. Mendes, A Resource Reservation Protocol Supporting QoS-aware Multicast Trees for Next Generation Networks, 12th IEEE Symposium on Computers and Communications (ISCC), Aveiro, Portugal, 2007. [8] A. Neto, E. Cerqueira, M. Curado, E. Monteiro, P. Mendes, Scalable Resource Provisioning for Multi-user Communications in Next Generation Networks, IEEE Globecom - Next Generation Networks, Protocols, and Services Symposium, New Orleans, LA, USA, 2008. [9] R. Hancock, G. Karagiannis, J. Loughney and S. Van den Bosch, Next Steps in Signalling (NSIS): Framework, IETF RFC 4080, June 2005 [10] S. Bhattacharyya, An overview of Source-Specific Multicast (SSM), IETF RFC 3569, July 2003 [11] The NS-2 Home Page, http://www.isi.edu/nsnam/ns/.

Figure 7. Jitter over time

The results demonstrates a significant improvement from 0.81 ms (Legacy C-CAST), to 0.42 ms (Advanced C-CAST), which notices an improvement of 48,14% for Advanced CCAST in this concrete simulation. The jitter and delay improvement may be justified by the fact that Advanced CCAST selected best paths, associated to the reduced signalling load which optimizes the networking processing throughout the network system. VI. CONCLUSION AND FUTURE WORK In this we presented the Advanced C-CAST, which rearchitects the Legacy C-CAST architecture to support the integrated over-provisioning of per-class over-reservations and the multi-party transport overlay structures in a system with multiple ingress nodes. Advanced C-CAST improves the performance level of Legacy C-CAST by allowing a drastic reduction of signalling load for network resource control, which envisions optimizing the overall rates of processing/state overhead and energy consumption while improving bandwidth use throughout the system. In order to confirm the benefits of Advanced C-CAST over Legacy CCAST, a preliminary performance evaluation was carried out in a simulator. For this work, the Advanced C-CAST was evaluated against the Legacy configuration, in the sense to determine its in different situations, taking signalling load, delay and jitter over the simulation time as preliminary benchmarking. The outcomes of the simulations demonstrated that Advanced C-CAST enhances Delay and Jitter rates of 31.9% and 48.14% respectively, while optimizing the mean signalling load in 34.26%. Moreover, the centralized