Evaluation of the BRAIN Candidate Mobility Management ... - CiteSeerX

1 downloads 0 Views 194KB Size Report
IST project BRAIN has proposed a full IP-based Radio Access Network .... The BRAIN Access Routers (BARs) which are located at the edge of the BRAIN AN ...

Evaluation of the BRAIN Candidate Mobility Management Protocol Csaba Keszei1, Nikos Georganopoulos2, Zoltan Turanyi3, Andras Valko4 1,3,4 2

Ericsson Research, {firstname.familyname}@eth.ericsson.se

Centre for Telecommunications Reserch, Kings College London, UK [email protected]

Abstract: In the context of the research in the IST project BRAIN, an in-depth study of the problem of IP mobility within the access network was performed. Mobility management was broken down to individual issues, which were separately analysed. Requirements, design goals, and recommendations for an ideal solution were proposed. Various existing proposals were considered against these requirements as a possible solution for the BRAIN access network. The outcome of this research activity was the proposal of a new IP mobility management protocol as a candidate solution for the BRAIN networks. This paper will present the functionalities of this BRAIN Candidate Mobility Protocol (BCMP). Furthermore the protocol was simulated, thus proving the correctness of its operation and its performance is evaluated through simulations. This paper will present qualitative and quantitative results of these simulations.

I.

Introduction

IST project BRAIN has proposed a full IP-based Radio Access Network architecture for systems beyond 3G [BRAIN01]. Two of the main issues considered on such a system are mobility management and quaility of service. Mobility of terminals has recently been one of the most important topics in the research community. Hosts normally belong to their home network, i.e. their home address can be accessed through standard routing. When hosts move to a new network and continue their movement, their address is no longer routable in the new location. Thus, mobility of hosts presents the network with the problem of routing the packets to the terminal’s new point of attachment to the network. The main goals of the mechanism supporting mobility are, to: • Ensure the break in communications during the handover is as short as possible and that no (or only a few) packets are lost. Hence all applications, including real-time, can be supported. • Minimise signalling overhead to achieve the re-routing. This includes the load and the delay, and also the storage and processing requirements at each router. Solutions to the basic mobility problem involve establishing some sort of dynamic mapping between the mobile host’s (MH’s) permanent identifier (who does the correspondent host (CH) want to communicate with) and its current location (how to route packets through the network between the CH and the MH). In order to fulfil the above-mentioned attributes it is preferable to decouple the mobility management inside the access network (AN) and through the core network. Hence by managing mobility locally, micro mobility protocols exploit the significant ‘localisation’ of a MH’s movement. In this way, routes are updated through access network routers inside the AN, avoiding signalling messages to network components far from the current location of the MH, thus reducing the signalling load in the core network and improving the re-routing latency. Macro mobility, thus deals with the movement of a MH to a new AN, whereas micro mobility deals with the movement of the MH inside the same AN. Mobile IP [MIP96] and SIP [SIP00] are examples of protocols used for macro mobility management, whereas there are numerous protocols for local mobility management such as Cellular IP [CIP00], HAWAII [HAW00], Hierarchical MIP [HMIP00] and many others. A complete list of the various terms that are used in the context of micro mobility in an access network, can be found in [TERM01].

II.

Local Mobility Management

Although most architectures in the literature deal with mobility management in the AN as a complex single problem, in BRAIN the problem was broken down into separate issues. There are three main functions, as identified in BRAIN, that an IP-mobility solution must provide. Since each concentrates on meeting different requirements, they can be analysed largely separately:

• Packet forwarding and Path Updates: This refers to the mechanism for installing information in the interior of the AN so that packets can be successfully delivered to the MH at its new Access Router (AR). Its requirements include: o Scalability – to cope with a large network with many mobiles o Robustness – there should be no single point of failure and there needs to be quick automatic recovery from network node and link failures. The Packet forwarding and Path Update solution should allow multiple gateways, because this improves scalability and reliability. • Handover Management: This refers to the impact of handovers on the MH. It deals with the local signalling involving the MH and the ARs to facilitate re-attachment to a new AR. The aims are to: o Minimise packet loss and delay during a handover o Make use of any “triggers” available (e.g. information that a handover is imminent from the MH at the link layer or from the network), in order that action can be taken in advance of the actual handover o Allow the possibility of passing context (QoS, security, header compression state, etc) from the old AR to the new AR, and also any buffered packets o Ensure that a planned handover can fall back gracefully to an unplanned one (in case it fails), and that the same actions can happen (transferring buffered packets and context) o Allow inter-technology handovers (if the MH can support them) • Support for Idle Mobile Hosts: An idle MH (i.e. one not actively transferring packets), can reduce its signalling messages over the air and thus save on its terminal power. Its locations is coarsely tracked through a combination of paging and location updates, which respectively reduces router state in the AN. Paging needs to be scalable and reliable. Analysis of these functional issues together with further issues including support of multiple gateways for network resilience and scalability was performed, and a detailed framework for the desired solution was produced. Although these three main issues can be considered individually, they are not totally independent and interactions between them exist. Existing protocol proposals have been studied [EARD00], and the solutions they could provide to the BRAIN access network were evaluated [KESZ00].

III.

BRAIN Candidate Mobility Protocol

A thorough analysis of the individual issues was performed and a detailed framework for individual solutions was set. This task has shown that it is very difficult to find a solution that can satisfy all the separate requirements. However, within BRAIN, a new mobility management protocol was proposed that is a strong candidate for inclusion within the specified framework and in meeting the requirements listed above. The key features of the protocol are summarised below, while its outline operation is illustrated in Figure 1. Generally, the access network consists of legacy IP routers. In order to support the protocol, mobility aware functionality is embedded in key components of the AN: • The BRAIN Access Routers (BARs) which are located at the edge of the BRAIN AN and offer IP connectivity to the MH. They act as the default router to the MHs that they serve. • The Anchor Point (ANP) which are located ‘inside’ the AN at different selected positions. ANPs own and allocate IP addresses, authenticate users, maintain user records, and tunnel packets towards MHs. The BAR terminates tunnels from ANPs and forward packets to/from MHs. In this context, the BRAIN Mobility Gateways (BMGs) do not need to have mobility specific functionality – their role is that of a standard border router, shielding the rest of the AN from the exterior routing protocols and distributing traffic within the AN to the correct ANPs. This decoupling of the boundary (BMGs) and mobility specific (ANPs) functionality allows for more flexibility in the selection and deployment of network components. It also makes an explicit boundary that looks like a fixed-network boundary. ANPs have a globally routable address space and they allocate IP addresses to MHs when they log in to the AN. This address is kept constant, despite handovers. The pool of IP addresses owned by an ANP is advertised using legacy IP routing inside the AN and towards external IP networks. This ensures that packets addressed to a MH’s locally obtained address are prefix-based routed to the ANP that allocated the address. ANPs, in turn, tunnel packets to the BAR where the destination MH is

currently located. ANPs must maintain up-to-date location information of MHs they have allocated an address for and must update this information when ‘their’ MHs change BAR.

BMG

ANP

BMG

ANP

BMG

ANP

BAR

ANP

BAR BAR

BAR

BMG

ANP

BMG

ANP

BAR

ANP

BAR BAR

BAR

BMG

ANP

ANP

BAR

BAR BAR

BAR

MH MH

MH

Figure 1: BCMP Overview

The main procedures that are covered by the protocol are: • Login - Address Management and Security: When the MH first contacts the AN it must execute a login procedure. First it sends a login request message to the BAR at which it has appeared. In this request the MH provides login and security information for an external AAA procedure. The BAR selects an ANP for the MH according to a policy specified by the operator and forwards the login request to it. The MH need not be aware of the policy or of the internal structure of the AN. The selected ANP executes the AAA procedure to identify and authenticate the MH and allocates a globally routable IP address and a new Session Identifier for the MH, which is a temporary identifier for the MH. The session id, key and IP address are sent back to the MH in a login response message. • Handover and Path Updates: The protocol includes an optional handover preparation phase to ensure fast and smooth handover. If the MH knows in advance to which BAR it is moving (i.e., planned handover), then it can build a temporary tunnel from the old BAR to the new BAR. The handover execution procedure is the same whether or not there has been a preparation phase. It is initiated by the new BAR and the main task is to inform the old BAR about the handover and stop transmitting over the air. This concludes the handover. The new BAR also sends the handover message to the ANP. In response the ANP will redirect the tunnel to the new BAR and notify the old BAR. Upon receiving this notification the old BAR can safely remove the temporary tunnel because it will certainly not receive more packets from the ANP. This concludes the path update. BCMP's HO management fits in IETF's general IP handoff work • Inter-Anchor Handover: If a MH moves far away from its ANP then the tunnel between the ANP and serving BAR may become very long. In order to avoid long tunnels, the protocol allows (but does not mandate) the network operator to request that a MH changes ANP. This improves routing efficiency in the AN in exchange for exposing mobility toward the Internet: the change of ANP requires changing the MH’s IP address, which is a global mobility event. Alternatively, operators may choose to accept long tunnels between ANPs and BARs in order to completely hide mobility from external networks. • Paging: Paging support in the protocol allows MHs to enter idle mode and to reduce location update signalling load inside the AN. Downlink packets are tunnelled to a MHs last known serving BAR, which knows that the MH is idle and so initiates the paging process. Summarising BCMP, including the above functionalities, is compliant with the general framework and requirements of the individual issues already mentioned. BCMP follows a tunnelled approach which unlike the per-host forwarding schemes (HAWAII, CIP,…) can be implemented on few existing routers and can be slowly rolled out. Compared to HMIP, the MH communicates only with the BAR in all cases and is not aware of the protocol inside the BAN, e.g., does not know the IP address of the ANP. It has its own message set and does not reuse or extend MIP's messages, i.e BCMP is also independent of the macro mobility protocol used.

IV.

Protocol Simulation:

The actual topology of the BRAIN Access Network is not standard and will vary according to the sites where a network provider would deploy a BRAIN network. The focus of this study is on the strict-tree (or hierarchical) topology and the relaxed-tree (or partial mesh) topology. Proposed micro mobility proposals such as Cellular IP, Hawaii and Hierarchical MIP are designed for optimum performance when operating in a tree topology (physical or logical) and when operated in a partial mesh topology (physical), their operation would either be exactly the same (CIP, HMIP) or can lead to sub-optimal routing (HAWAII) [KESZ00]. BCMP is designed to operate irrespective of the network topology and this study evaluates the performance of the protocol for both cases, tree and partial mesh topology.

Figure 2: BRAIN Access Network Topologies

Of course an actual network topology would be a mixture of a tree and mesh topology, but this study presents the two extreme cases, letting the reader conclude on the performance in different types of networks. One of the main features of BCMP is its scalability and flexibitlity, scaling from campus networks up to large area networks, by varying the position and number of the ANPs. Although the ‘width’ of such network varries, the ‘depth’ in terms of the distance of the BARs from the core network is approximately represented in the topologies. In the hierarchical topology (Figure 2) there is one BMG to the core network and the position of the ANPs is varied from, only one (Set-up A) on node ‘7’ (which acts as BMG as well), to six on nodes ‘13’, ‘14’, ‘15’, ‘16’, ‘17’ and ‘18’ (Set-up D). In this topology the number of ANPs increases as they are placed closer to the BARs, since this will ensure good overall performance. In the partial mesh topology there are two BMGs to the core network and the number of ANPs is either two- on nodes ‘7’ and ‘9’ (acting also as BMGs) (Set-up A) or on nodes ‘10’ and ‘13’(Set-up B)- or three ANPS on nodes ‘14’, ‘16’ and ‘18’ (Set-up C), or ‘20’, ‘22’ and ‘24’ (Set-up D). From the protocol specifiction it is evident that the number of ANPs can affect the number of inter-Anchor handovers which involve signalling for global mobiltiy updates. Network simulator ns-2 was used to perform a large number of simulations, with different network topology configurations, to evaluate its performance. It is ensured that packets are not lost due to network congestion or lossy wireless links, but only due to the mobility of the MH. Due to space limitations, it is impossible to present all the results here and only few will be shown representing the general performance of BCMP. A multimedia traffic scenario was used with both TCP and UDP based applications and the link capacity was chosen sufficiently high to ensure that packet delay or loss is caused only to mobility and not network congestion. There are in total 24 MHs that attach to the network of which only two are moving, performing handovers. Simulations run for 12 seconds and moving MHs perform 11 handovers each. IV.I. Planned Handover (No Anchor change) In the case of planned handover, a temporary tunnel is built between old and new BAR, the MH sets up the link to the new BAR and then performs a handover. The movement of the MH in the BAN happens without changing its initially given address. In this case there are no lost packets during the handover and Table 1 summarizes the disruption in terms of reordered packet received by the MH. The out of order packets have a different impact on TCP and UDP applications. Figure 3 shows the

Hierarchical TCP UDP 29 22 27 23 31 21 38 16

Set-up A Set-up B Set-up C Set-up D

achieved throughput that one TCP connection (FTP application) achieves over the network and how this is affected by the packet reordering. In the case of UDP applications, its of interest to measure the end-to-end delay of the UDP packets and the delay jitter. Figure 4 plots these together with the maximum delay that UDP packets face during handovers, when packets are forwarded from the old

Partial Mesh TCP UDP 1 1 1 0 1 0 0 1

Table 1: Out of Order Packets - Planned

BAR to the new BAR. TCP Throughput

throughput (MBps)

throughput (MBps)

TCP Throughput 3 2.5 2

3 2.5 2 1.5

1.5

1

1 Set-up A Set-up B Set-up C Set-up D

0.5

Set-up A Set-up B Set-up C Set-up D

0.5

0

0 0

2

4

6

8

10

12

14 time (s)

0

2

4

6

8

10

12

14 time (s)

Figure 3: TCP Throughput for Hierarchical and Partial Mesh Topologies UDP e2e Delay

UDP e2e Delay

max mean min

delay(s)

delay(s)

0.035

0.03

0.025

0.035

max mean min

0.03

0.025

0.02

0.02

0.015

0.015

0.01

0.01

0.005

0.005

0

0

Set-up A

Set-up B

Set-up C

Set-up D

Set-up A

Set-up B

Set-up C

Set-up D

Figure 4: UDP end-to-end Delay for Hierarchical and Partial Mesh Topologies

IV.II. Unplanned Handover (No Anchor change) Hierarchical Dropped TCP UDP 85 45 63 40 62 39 72 40

Set-up A Set-up B Set-up C Set-up D

The second feature of the BCMP is the performance during an unplanned handover. In this scenario the MH performs continuous unplanned handovers and always keeps its initial assigned address.

Partial Mesh

Reordered TCP UDP 33 13 46 11 31 11 22 13

Dropped TCP UDP 35 14 32 16 30 13 28 14

Reordered TCP UDP 0 3 1 2 2 1 6 0

Table 2: Packet Disruption during Unplanned Handover

TCP Max Sequence

seq. no.

seq. no.

TCP Max Sequence 7000 6000 5000

7000 6000 5000

4000

4000

3000

3000

2000

2000 Set-up Set-up Set-up Set-up

1000

A B C D

0

Set-up Set-up Set-up Set-up

1000

A B C D

0 0

1

2

3

4

5

6

7

8

9

10

11

12 13 tim e (s )

0

1

2

3

4

5

6

7

8

9

10

11

Figure 5: TCP Packet Sequence Number for Hierarchical and Partial Mesh Topologies

12 13 time (s)

As can be seen from Table 2 there is disruption as packets are dropped and also reordered. Figure 5 plots the maximum TCP packet sequence number that is transmitted during the simulation since the disruption in throughput makes it difficult to distinguish between the graphs for different network set-ups. For UDP applications apart from the packet loss, the e2e delay varies similarly to the previous case. IV.III Inter-Anchor Handover (Planned Handover) The third feature of the BCMP is the performance during a change of Anchor that happens when a MH has moved away from his ANP. In this scenario the MH performs continuous planned handovers and when the new BAR is nearer a new ANP, inter-Anchor handover occurs. During the change of Anchor all packets arriving at the old ANP are tunnelled to the new ANP, who then forwards to the MH through its serving BAR. The Hierarchical Partial Mesh new ANP assigns a new address to the MH and TCP UDP TCP UDP also keeps sending the MH the packets from the Set-up A 2 1 old ANP. MH gets the new address and sends it to Set-up B 3 1 2 3 the HA who updates it and continues tunnelling Set-up C 4 2 0 2 packets to the new ANP. The same metrics as in Set-up D 12 8 2 1 the previous cases are shown and plotted in Table Table 3: Out of Order Packets Inter-Anchor HO 3, Figure 6 and Figure 7. TCP Throughput throughput (MBps)

throughput (MBps)

TCP Throughput 3 2.5 2 1.5

3 2.5 2 1.5

1

1

Set-up B Set-up C

0.5

Set-up A Set-up B Set-up C Set-up D

0.5

Set-up D 0

0

0

2

4

6

8

10

12

14 time (s)

0

2

4

6

8

10

12

14 time (s)

Figure 6: TCP Throughput for Hierarchical and Partial Mesh topologies UDP e2e Delay

delay(s)

delay(s)

UDP e2e Delay 0.035

max mean min

0.03

0.035

max mean min

0.03

0.025

0.025

0.02

0.02

0.015

0.015

0.01

0.01

0.005

0.005

0

0 Set-up A

Set-up B

Set-up C

Set-up D

Set-up A

Set-up B

Set-up C

Set-up D

Figure 7: UDP end-to-end Delay for Hierarchical and Partial Mesh Topologies

V.

Discussion

The results prove that BCMP is a complete protocol that can operate in both network topologies without any failures. However, is also evident from the above tables and figures that particularly good performance occurs when operating in a partial mesh topology. In the case of a planned handover packet reordering triggers TCP’s fast retransmit algorithm and congestion recovery is employed for the hierarchical topology. This does not happpen in the mesh topology since the out of order packets are very few (Table 1). TCP throughput in both cases decreases as the MH moves away from its ANP(Figure 3,Figure 4). In both topologies set-up D (ANPs close to BARs) results in the largest throughput reduction, wich is smaller than 20%. For UDP the average e2e delay is smaller for set-up A (ANPs are BMGS) in both topologies, and the maximum delay is larger in the hierarchical topology. Although link capacity is chosen high enough, some delay in the network occurs espcecially since First Come First Serve (FCFS) queues are implemented in the network routers.

In the case of unplanned handover packets are lost and the service disruption is shown in terms of packets lost and reordered in Table 2. Of course TCP has to recover from packet loss and Figure 5 plots the packet sequence number. This is normal since the unplanned handover is a graceful fallback in case of unsuccesful handover preparation. In this case no change of Anchor is performed resulting in lowest throughput for set-up D and set-up C and B having the best performance. For UDP the results are very similar to the case of planned handover. Thus, except from the packet loss, the performance in terms of e2e delay is similar. In the last case of inter-Anchor handover Table 3 summarises the packet reordering that is a result of the change. This may trigger TCP fast retransmit in the hierarchical topology, but the graphs in Figure 6 must be considered keeping in mind the fact that planned handovers are performed as well during the simulation. In the mesh topology the throughput remains at its highest level throughout the simulation giving the best performance. Likewise for UDP (Figure 7) the average e2e delay remains low and is the same for all different network set-ups.

VI.

Conclusions

In this paper an initial evaluation of the performance of a new micro mobility management protocol, which is proposed as a candidate for the BRAIN access network, was performed. Two main network topologies were considered and the network set-up in terms of the number and position of the Anchors was also varied. The results of this study have shown that the best performance is achieved in a mesh topology although the protocol can operate in a hierarchical topology as well. Regarding the number and position of the anchors, this is an issue that depends on the size, nature and resilience of the network. Of course having few Anchors close to the core network results in better performance and fewer address changes. This should be desired for small scale networks, but as the size of the network grows more anchors should be included and their prefered position should be in the ‘middle’ of the network regarding its distance from the different BMGs and BARs. This is a design implementation issue and heavily depends on the actual network size and topology. What is evident though is the versatality of BCMP that can be easily installed on different kinds of networks, including existing ones since it requires upgrade of only few network components, the Anchors and the ARs. Future work for BCMP includes more detailed study of the scalability and resilience issues. This should include a quantitative work in terms of link and system capacity, number of MHs that an Anchor can support, number of gateways the system can have, etc... Furthermore a simulation based performance comparison with other proposals (CIP, HAWAII and HMIP) would determine the advantages and disadvantages of BCMP.

Aknowledgements This work has been performed in the framework of the IST project IST-1999-10050 BRAIN, which is partly funded by the European Union. The authors would like to acknowledge the contributions of his colleagues from Siemens AG, British Telecommunications PLC, Agora Systems S.A., Ericsson Radio Systems AB, France Télécom R&D, INRIA, King’s College London, Nokia Corporation, NTT DoCoMo, Sony International (Europe) GmbH, and T-Nova Deutsche Telekom Innovationsgesellschaft mbH.

References

[BRAIN01] Eardley P., Hancock R. “Modular IP architecture for wireless access”, 2nd International BRAIN Workshop, Yokosuka, February 2001. [CIP00] Cambell, A. T., Kim, S., Gomez, J., Wan, C-Y., Turanyi, Z., Valko, A., "Cellular IP”, IETF, (work in progress), January 2000. [EARD00] Eardley P., Mihailovic A., Suihko T. “A Framework for the Evaluation of IP Mobility Protocols”, PIMRC ’00, London, September 2000. [HAW00] Ramjee, R. , La Porta, T. , Thuel, S., Varadhan, K. , “IP micro-mobility support using HAWAII”, IETF, (work in progress), July 2000. [KESZ00] Keszei C., Manner J., Turányi Z., Valko A., “Mobility Management and QoS in BRAIN Access Networks”, 1st International BRAIN Workshop, London, November 2000. [MIP96] Perkins, C., "IP Mobility Support", IETF, RFC 2002, October 1996. [SIP00] E. Wedlund, H. Schulzrinne, “Mobility support using SIP”, ACM Mobile Computing and Communications Review, vol. 4, no. 3, July 2000. [TERM01] Manner J., Kojo M., Suihko T., Hankock R., Wisely D., Eardley P. Georganopoulos N., “Mobility related Terminology”, IETF, , (work in progress), July 2001.

Suggest Documents