Wireless Future - Telenor

More documents

Recommendations

Info

84 IETF Internet Engineering Task Force IP Internet Protocol ICMP Internet Control Message Protocol LCOA Local Care-of Address LCA Least Ancient Ancestor MAP Mobility Anchor Point MIP Mobile IP MH Mobile Host QoS Quality of Service RSVP Resource Reservation Protocol TCP Transport Control Protocol UDP User Datagram Protocol 2 Mobile IP There are some technical obstacles that must be overcome before mobility in the Internet can be a reality. The most fundamental obstacle is the way the Internet Protocol routes packets to their destinations according to IP addresses. These IP addresses are associated with a fixed network location much as a non-mobile phone number is associated with a physical jack in the wall. When a mobile node moves from one point of attachment to another, the mobile node must change its IP address so it is associated with the new network number, thus making transparent mobility impossible. Mobile IP [1] is a standard proposed by a working group in the Internet Engineering Task Force (IETF) which is designed to solve the mobility problem by allowing the mobile node to use two IP addresses; a fixed home address and a care-of address that changes at each point of attachment. The proposal introduces a Home Agent that resides at the home network and tunnels packets destined to mobile nodes to their new point of attachment, and a Foreign Agent that provides mobile services to mobile nodes. Mobile IP is completely transparent for all layers above IP, e.g. for TCP, UDP and of course for all applications. Therefore, DNS entries for a mobile node refer to its home address and do not change if the mobile node changes its Internet access point. Mobile IP consists of the co-operation of three mechanisms: • Discovering Agents and obtaining a care-of address; • Registering the care-of address; • Tunnelling to the care-of address. 2.1 Discovering Care-of Addresses The protocol used by mobile nodes to discover home and foreign agents is based on the existing protocol Router Advertisement [8]. Mobile IP does not modify any of the existing fields of the protocol, but expands it so that mobility functionality can be associated with it. This way a Router Advertisement can carry information about default routers, just as before, but in addition also contain information about one or more care-of addresses. Carrying this additional information, these router advertisements are called Agent Advertisements. Home and foreign agents will broadcast Agent Advertisements at regular intervals, typically once every one to ten seconds. If a mobile node needs a care-of address and does not wish to wait for an agent advertisement, the mobile node can broadcast (or multicast) a solicitation that will be answered by any home/foreign agent that receives it. Mobile nodes use router solicitation to detect any change in the set of mobility agents available at the current point of attachment. If advertisements are no longer detectable from a foreign agent that previously had offered a careof address to the mobile node, the mobile node should presume that the foreign agent no longer is within range of the mobile node’s network interface. In this situation, the mobile node should start looking for a new care-of address. The mobile node may choose to wait for an agent advertisement, or it may send an agent solicitation. 2.2 Registering the Care-of Address When a mobile node has a care-of address, it must inform its Home Agent about it. The mobile node will send a Registration Request message (carried in a UDP packet) with the information about its new care-of address. If the Home Agent approves this request, it will update its routing tables according to the new information and send a registration reply back to the mobile node. The registration request message is protected by an authentication mechanism. This is because when a Home Agent accepts a registration request, it will associate the home address of the mobile node with the care-of address until the registration lifetime expires. A registration request is a form of remote redirect, because it is sent remotely to the Home Agent and affects the home agent’s routing table. Without some sort of authentication for these remote redirect, a malicious node could cause the Home Agent to alter its routing table with erroneous care-of address information. 2.3 Tunnelling to the Care-of Address Figure 2-1 shows the main principle of the mobile IP tunnelling operation. The default encapsulation mechanism that must be supported by all mobility agents using Mobile IP is IPwithin-IP [2]. The Home Agent intercepts datagrams addressed to the mobile nodes and inserts an extra IP header, or tunnel header, in front of the IP header of the datagrams. The new tunnel Telektronikk 1.2001
header uses the mobile node’s care-of address as the destination IP address, or tunnel destination. The tunnel source is the home agent. 2.4 Triangle Routing All the datagrams that are sent to the mobile node must be routed through the Home network, being encapsulated and tunneled by the Home Agent using IP-in-IP encapsulation. Datagrams sent from a mobile node to a corresponding node on the other hand can be sent directly using standard IP routing. This is shown in Figure 2-2. This asymmetric routing is called Triangle Routing and is in general far from optimal, especially when the mobile node is close to the corresponding node. An extension to Mobile IPv4 introduces the possibility for a Home Agent to inform corresponding nodes of the mobile node location. When a node tries to send a datagram to a mobile node, the Home Agent can provide information about the care-of address by sending what is called a Binding Update (BU). The BU is carried in a UDP packet with the mobile node’s care-of address in addition to other parameters such as the lifetime of the care-of address. The corresponding node can now send datagram directly to the mobile node by setting up its own tunnel, thus getting a more optimal routing. 2.5 Mobile IPv6 Mobile IPv6 [3] includes many features for streamlining mobility support that are missing in Mobile IPv4. The design of Mobile IP support in IPv6 (Mobile IPv6) represents a natural combination of the experiences gained from the development of Mobile IP support in IPv4 together with the opportunities provided by the design and deployment of a new version of IP itself (IPv6) and the new protocol features offered by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, but the protocol is now fully integrated into IP and provides many improvements over Mobile IPv4. Mobile IPv6 requires the exchange of additional information. All new messages used in Mobile IPv6 are defined as IPv6 Destination Options. The most important improvements are listed below. Route Optimisation Route Optimisation is now built in as a fundamental part of the protocol, rather than being added on as an optional set of extensions that may not be supported by all nodes as in Mobile IPv4. This integration of Route Optimisation functionality allows direct routing from any correspondent node to any mobile node, without needing to pass through the mobile node’s home network and be forwarded by its Home Agent, Telektronikk 1.2001 Tunnel end point Outer IP Header Original IP Header Original IP payload Mobile node Tunnel and thus eliminating the problem of triangle routing present in the base Mobile IPv4 protocol. Ingress Filtering Support is also integrated into Mobile IPv6 and into IPv6 itself for allowing mobile nodes and Mobile IP to coexist efficiently with routers that perform Ingress Filtering. A mobile node now uses its care-of address as the Source Address in the IP header of packets it sends, allowing the packets to pass normally through ingress filtering routers. The home address of the mobile node is carried in the packet in a Home Address destination option, allowing the use of the careof address in the packet to be transparent above the IP layer. The ability to correctly process a Home Address option in a received packet is required in all IPv6 nodes, whether mobile or stationary, whether host or router. Foreign Agents There is no longer any need to deploy foreign agents as used in Mobile IPv4. In Mobile IPv6, mobile nodes make use of IPv6 features, such as Neighbour Discovery and Address Autoconfiguration, to operate in any location away from home without any special support required from its local router. Home Agent IP-in-IP encapsulation Foreign Agent Original IP Header Original IP payload Datagram from the corresponding node is routed via the Home Agent Foreign Agent Home Agent Figure 2-1 Tunnelling of IP datagram Figure 2-2 Triangle routing in Mobile IPv4 Internet node Datagram routed directly to the corresponding node Mobile node 85
Page 2 and 3:
Telektronikk Volume 97 No. 1 - 2001
Page 4 and 5:
Per Hjalmar Lehne (42) obtained his
Page 6 and 7:
Stein Svaet (41) is Senior Research
Page 8 and 9:
Pbit/day 6 150 125 100 75 50 25 0 F
Page 10 and 11:
8 Video communication as a utility
Page 12 and 13:
10 The idea of reconfigurable mobil
Page 14 and 15:
12 Switched lobe Dynamically phased
Page 16 and 17:
Figure 10 The All IP vision Figure
Page 18 and 19:
16 The IP world has some problems t
Page 20 and 21:
18 Abbreviations and acronyms less
Page 22 and 23:
Jorge Pereira (40) obtained his Eng
Page 24 and 25:
(Millions) Figure 1 Exponential gro
Page 26 and 27:
24 Defining Generation based upon D
Page 28 and 29:
Multi-mode Terminal by Software Rad
Page 30 and 31:
distribution layer possible return
Page 32 and 33:
30 A Co-Ordinated Approach to 4G As
Page 34 and 35:
Figure 2 Applications will grow fas
Page 36 and 37: Figure 5 Evolution from multi-mode
Page 38 and 39: Operator/Provider download librarie
Page 40 and 41: Radio network subsystem - service c
Page 42 and 43: Dr. Techn. Jørgen Bach Andersen (6
Page 44 and 45: Figure 3 Two arrays with M and N el
Page 46 and 47: Figure 5 Cumulative probability dis
Page 48 and 49: Figure 8 As in Figure 5, but with F
Page 50 and 51: 48 Conclusion The challenge of prov
Page 52 and 53: 50 models are described simply by a
Page 54 and 55: 52 ping intervals or “quantizatio
Page 56 and 57: Figure 3 ASE as a function of the a
Page 58 and 59: 56 7 Conclusion and Further Researc
Page 60 and 61: Dave Wisely (39) graduated in 1982
Page 62 and 63: Figure 2 Business case study Figure
Page 64 and 65: Figure 6 BRAIN QoS architecture 62
Page 66 and 67: 64 4 BRAIN homepage. (2001, March 6
Page 68 and 69: Figure 2 The Bluetooth protocol sta
Page 70 and 71: Figure 5 A Bluetooth radio module i
Page 72 and 73: 70 • Instant postcard: A Bluetoot
Page 74 and 75: 72 work visions come true, it is ne
Page 76 and 77: Table 1 Allocated HiperLAN bands (i
Page 78 and 79: Figure 4 Basic MAC frame structure
Page 80 and 81: 78 Preamble BCH FCH ACHs Preamble S
Page 82 and 83: throughput bit/s 80 3 2.5 2 1.5 1 0
Page 84 and 85: 82 5 References 1 CEPT. ERC Decisio
Page 88 and 89: Figure 2-3 Mobile IPv6 architecture
Page 90 and 91: 88 domain, it attaches to a new lea
Page 92 and 93: 90 Domain GFA/MAP Figure 3-3 Archit
Page 94 and 95: Geir Gylterud (35) is Research Scie
Page 96 and 97: 94 Framework Resource Resource Int
Page 98 and 99: Figure 6 SCSs and network functiona
Page 100 and 101: Figure 9 The new business model. Fr
Page 102 and 103: 100 A strong consortium backs up th
Page 104 and 105: 102 Music Company Figure 3 Service
Page 106 and 107: Figure 4 OSA architecture service c
Page 108 and 109: Do van Thanh (43) obtained his MSc
Page 110 and 111: Figure 2 The first use case diagram
Page 112 and 113: 110 Box 1 - The Open Service Archit
Page 114 and 115: 112 X:User 1:Device 2:Device 3:Devi
Page 116 and 117: Figure 10 Initiating call from PSTN
Page 118 and 119: Figure 13 Splitting the incoming st
Page 120 and 121: Figure 17 A set of communication de
Page 122 and 123: 120 Box 3 continued Session Descrip
Page 124 and 125: Figure 21 A laptop and peripheral d
Page 126 and 127: 124 Box 4 - Bluetooth Bluetooth is
Page 128 and 129: 126 6 The ICEBERG project. (2001, M
Page 130 and 131: 128 new door towards the upcoming f
Page 132 and 133: ? Figure 1 The Mobile Service Platf
Page 134 and 135: Figure 2 Needs and Related Services
Page 136 and 137:
134 Telektronikk 1.2001
Page 138 and 139:
136 Telektronikk 1.2001
Page 140 and 141:
Anne Lise Lillebø (52) is Adviser
Page 142 and 143:
140 with other SDOs (Standards Deve
Page 144 and 145:
142 Box 2 - ETNO Declaration We, th
Page 146 and 147:
Arve Meisinset (52) is Senior Resea
Page 148 and 149:
146 In ITU-T we have seen needs to
Page 150 and 151:
148 Each viewpoint constitutes a se
Page 152 and 153:
Figure 2 UML class diagrams for tra
Page 154 and 155:
152 The functionality describing th
Page 156 and 157:
154 9 Potter, B et al. An introduct
show all

Wireless Future - Telenor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?