[PPT] - Internetworking with satellite constellations PhD viva presentation PowerPoint Presentation

SLIDE 1

Internetworking with satellite constellations

PhD viva presentation Centre for Communication Systems Research, University of Surrey 11am, Wednesday, 21 February 2001.

Lloyd Wood

http://www.ee.surrey.ac.uk/Personal/L.Wood/

work done in the Networks Group, Centre for Communication Systems Research, University of Surrey.

SLIDE 2

Internetworking with satellite constellations - Lloyd Wood 2

Overview of this talk and Lloyd’s PhD work:

Geometry; orbital constraints, mesh network topology,

handover and routing give path delays across constellation.

TCP across LEO/MEO mesh networks – performance

influences the approach to routing design.

Multicast – a simple core-based approach; place the core

(and its network state), shape the resulting tree.

Controlled handover in rosette geometries for classes
f service with smaller path delay variation.
Architecture – support IP QoS and multicast using

MPLS for a single control plane.

SLIDE 3

Internetworking with satellite constellations - Lloyd Wood 3

With intersatellite links (ISLs)

Satellites aren’t just ‘last hop’. Users don’t need to be in same satellite footprint as gateway station for connectivity. Coverage over remote areas (oceans) where there is no local infrastructure possible. Physical delay within space segment highly variable but deterministic; depends

n where terminals and gateways are, path

between them. May not be symmetrical. Can neglect ground segment. Can model space segment, find delay. Onboard processing, switching, routing are necessary. It’s a network.

example constellations: Iridium, Teledesic, Spaceway Without intersatellite links

Satellites are just ‘last hop’. Users need to be in same satellite footprint as gateway station for connectivity. Coverage over remote areas (oceans) where there is no local infrastructure not possible. Physical delay within space segment highly predictable and small; depends entirely on terminal-satellite-gateway hops during passes; likely to be symmetrical. Delay in ground segment unknown. Resulting total delay unknown. Onboard processing, switching are

ptional. No onboard routing.

example constellations: Globalstar, ICO, Skybridge

SLIDE 4

Internetworking with satellite constellations - Lloyd Wood 4

Concentrated on the satellite constellation with ISLs

It’s a single network. An autonomous system; single

point of control and management (not a military viewpoint).

Constraints of orbital motion and coverage mean

that network can be defined and simulated with accuracy.

Speed of light is a constraint. ISL propagation delay is

largest factor, subsuming all others.

What does traffic across the constellation experience?

How do applications see it? Focus on delay perspective. Latency indicates performance. (Congestion is multivariable; too many starting assumptions required to simulate congestion accurately.)

SLIDE 5

Internetworking with satellite constellations - Lloyd Wood 5

Constellation geometry - star vs rosette (LEO/MEO ISL designs)

−120

1a 1b 1c 1d 1e 2a 2b 2c 2d 2e 3a 3b 3c 3d 3e 4a 4b 4c 4d N

120 90 −30 30 −60 60 150 −150 −90 60 30 −60 −30

S

Background map rendered by Hans Havlicek (http://www.geometrie.tuwien.ac.at/karto/)

4e

−120

1a 1b 1c 1d 1e 1f 1g 1h 1i 1j 1k 1l 1m 1n 1o 1p 1q 1r 1s 1t 1u 1v 1w 1x 2a 2b 2c 2d 2e 2f 2g 2h 2i 2j 2k 2l 2m 2n 2o 2p 2q 2r 2s 2t 2u 2v 2w 2x 3a 3b 3c 3d 3e 3f 3g 3h 3i 3j 3k 3l 3m 3n 3o 3p 3q 3r 3s 3t 3u 3v 3w 3x 4a 4b 4c 4d 4e 4f 4g 4h 4i 4j 4k 4l 4m 4n 4o 4p 4q 4r 4s 4t 4u 4v 4w 4x 5a 5b 5c 5d 5e 5f 5g 5h 5i 5j 5k 5l 5m 5n 5o 5p 5q 5r 5s 5t 5u 5v 5w 5x 6a 6b 6c 6d 6e 6f 6g 6h 6i 6j 6k 6l 6m 6n 6o 6p 6q 6r 6s 6t 6u 6v 6w 6x 7a 7b 7c 7d 7e 7f 7g 7h 7i 7j 7k 7l 7m 7n 7o 7p 7q 7r 7s 7t 7u 7v 7w 7x 8a 8b 8c 8d 8e 8f 8g 8h 8i 8j 8k 8l 8m 8n 8o 8p 8q 8r 8s 8t 8u 8v 8w 8x 9a 9b 9c 9d 9e 9f 9g 9h 9i 9j 9k 9l 9m 9n 9o 9p 9q 9r 9s 9t 9u 9v 9w 9x 10a 10b 10c 10d 10e 10f 10g 10h 10i 10j 10k 10l 10m 10n 10o 10p 10q 10r 10s 10t 10u 10v 10w 10x 11a 11b 11c 11d 11e 11f 11g 11h 11i 11j 11k 11l 11m 11n 11o 11p 11q 11r 11s 11t 11u 11v 11w 11x 12a 12b 12c 12d 12e 12f 12g 12h 12i 12j 12k 12l 12m 12n 12o 12p 12q 12r 12s 12t 12u 12v 12w N

120 90 −30 30 −60 60 150 −150 −90 60 30 −60 −30

S

Background map rendered by Hans Havlicek (http://www.geometrie.tuwien.ac.at/karto/)

12x 90 60 30

30
60
90

30 60 90 120 150 180

30
60
90
120
150
180

unprojected latitude unprojected longitude

seam seam

ascending satellites (moving north) descending satellites (moving south) Quito Tokyo 10c London 1a 1b 1c 1d 1e 1f 1g 1h 1i 1j 1k 1l 1m 1n 1o 1p 1q 1r 1s 1t 1u 1v 1w 1x 2a 2b 2c 2d 2e 2f 2g 2h 2i 2j 2k 2l 2m 2n 2o 2p 2q 2r 2s 2t 2u 2v 2w 2x 3a 3b 3c 3d 3e 3f 3g 3h 3i 3j 3k 3l 3m 3n 3o 3p 3q 3r 3s 3t 3u 3v 3w 3x 4a 4b 4c 4d 4e 4f 4g 4h 4i 4j 4k 4l 4m 4n 4o 4p 4q 4r 4s 4t 4u 4v 4w 4x 5a 5b 5c 5d 5e 5f 5g 5h 5i 5j 5k 5l 5m 5n 5o 5p 5q 5r 5s 5t 5u 5v 5w 5x 6a 6b 6c 6d 6e 6f 6g 6h 6i 6j 6k 6l 6m 6n 6o 6p 6q 6r 6s 6t 6u 6v 6w 6x 7a 7b 7c 7d 7e 7f 7g 7h 7i 7j 7k 7l 7m 7n 7o 7p 7q 7r 7s 7t 7u 7v 7w 7x 8a 8b 8c 8d 8e 8f 8g 8h 8i 8j 8k 8l 8m 8n 8o 8p 8q 8r 8s 8t 8u 8v 8w 8x 9a 9b 9c 9d 9e 9f 9g 9h 9i 9j 9k 9l 9m 9n 9o 9p 9q 9r 9s 9t 9u 9v 9w 9x 10a 10b 10d 10e 10f 10g 10h 10i 10j 10k 10l 10m 10n 10o 10p 10q 10r 10s 10t 10u 10v 10w 10x 11a 11b 11c 11d 11e 11f 11g 11h 11i 11j 11k 11l 11m 11n 11o 11p 11q 11r 11s 11t 11u 11v 11w 11x 12a 12b 12c 12d 12e 12f 12g 12h 12i 12j 12k 12l 12m 12n 12o 12p 12q 12r 12s

c. Teledesic LEO satellite network (Boeing 288-satellite design, optimised coverage), showing simulated ground terminals

12x 12w 12v 12u 12t 90 60 30

30
60
90

30 60 90 120 150 180

30
60
90
120
150
180

unprojected latitude unprojected longitude ascending (moving north) and descending (moving south) satellites overlap 2e 1e 4e 3e 3d 2d 1d 4d 4c 3c 2c 1c 4b 3b 2b 1b 4a 3a 2a

b. Spaceway NGSO MEO satellite network with ISLs at a point in time, showing simulated ground terminals

London Tokyo Quito 1a

Teledesic (Boeing design - 288 active satellites) Hughes Spaceway NGSO (20 active satellites)

SLIDE 6

Internetworking with satellite constellations - Lloyd Wood 6

‘Twisted Manhattan’ satellite network variant

highest latitude highest latitude ascending satellites descending satellites

rbital plane -

constant intraplane ISLs maintained interplane ISLs - variable length

rbital seam

breaks these ISLs

Intersatellite links give us mesh networks...

0.000 0.100 0.200 0.300 0.400 0.500 0.600 Time (hours) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Shortest-path propagation delay time (seconds

1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 2 3 4 5 6 7 8 9 1 0 11 1 2 1 3 14 1 5 16 1 7 1 8 19 2 0 2 1 22 2 3 T Im e (h o ur s ) Nu m b er o f wir el es s lin k s ( h op s ) t ra ve rs ed

...and orbital motion gives us handover, path delay variation.

Path delay from Quito to London (by LEO/MEO/GEO)

path delay (milliseconds) over a day and as number of hops through the mesh:

SLIDE 7

Internetworking with satellite constellations - Lloyd Wood 7

So, taking path delay further…

Del ay b e tween terminals o n th e equ ator acro ss sea med Tel edesic 2 0 4 0 6 0 8 0 10 0 12 0 14 0 1 0 20 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 1 50 16 0 17 0 18 0 angle of se p ara ti on in longitude betw een t erm ina ls ( degrees)

tota l pr opa gati on delay seen a cr oss n etw ork p ath (m s) so lid bar i s del ay range f ro m max to mi n e rror b ar sh ows o n e sta ndard d eviatio n av era g e d ela y

D e la y b e tw ee n te rm in als o n e qu a tor a cro s s T e le d es ic wi th c ro ss -s ea m link s

20 40 60 80 1 00 1 20 1 40 10 2 0 3 0 4 0 50 60 70 8 0 9 0 1 00 1 10 1 2 0 13 0 14 0 150 1 60 1 70 18 0

a n gle o f s ep ar atio n in lo n g itu d e bet w ee n te r m in a ls (de gr ee s)

to t a l pro p a ga ti on d e l ay s e en o v er n e tw o rk p a th ( m s olid b a r is de l a y ra ng e f ro m m a x to m in e rror b a r sh o ws o ne s t anda r d d ev iat i

n

av e ra ge de lay

Teledesic with and without cross-seam links; every line shows a 24-hour simulation at a given latitude separation between terminals. Smaller delays and delay variation with cross-seam links. Note difference at 0º separation.

unprojected latitude −180 −150 −120 unprojected longitude 60 −90 −60 −30 180 150 120 90 60 30 90 30 −30 −60 −90 fixed range over which one terminal is moved angle of separation between terminals

SLIDE 8

Internetworking with satellite constellations - Lloyd Wood 8

Handover and packets in flight Star seam is a worst case, but there are transient spikes in path delay for packets in flight (subject to what your implementation does; could just drop packets with very hard handover…) every time your terminal undergoes a handover. This has implications for moving network state between satellites. If you don’t want to disrupt high-rate traffic, you want small spikes of no more than 1 ISL hop.

end-to-end packet delay variation over 1.4-hour period

total path delay packet transit time in ms (Y) s x 10-3 3 s x 10 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 0.0 1.0 2.0 3.0 4.0 5.0

packet destination as routing changes... ..travels a longer distance to goal. packet en route

later packets... ...take a shorter route.

3. 1. 2.

to or at this satellite

...take a shorter route. earlier packets before handover...

source elsewhere in network

SLIDE 9

Internetworking with satellite constellations - Lloyd Wood 9

TCP over the constellation mesh Examined interaction of fast recovery and delayed acks with multipath routing to simulate load balancing. TCP’s fixed three-dupack threshold presumes congestion, can’t cope with large amounts of reordering. Raise that threshold and performance improves.

growth exponential until loss or threshold is reached slow start avoidance congestion

ne segment

cwnd reduced to timeout TCP congestion window (cwnd) fast recovery window halved after loss

(1/cwnd growth)

linear time since TCP connection opened slowstart threshold

(ssthresh)

single segment sent fast retransmit congestion avoidance slow start growth linear FTP transfer over Teledesic using TCP New Reno

short any dupacks multipath 4/5 dupacks multipath 3 dupacks multipath 2 dupacks Amount of file transferred as seen by application (K) x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

FTP transfer over Teledesic using TCP SACK

short any dupacks multipath 5 dupacks multipath 4 dupacks multipath 3 dupacks multipath 2 dupacks Amount of file transferred as seen by application (K) x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

a. Transfers using New Reno TCP
b. Transfers using SACK TCP

Progress of FTP transfer between terminals at Quito and Tokyo using Teledesic.

effect of dupack threshold on throughput over multiple LEO paths

SLIDE 10

Internetworking with satellite constellations - Lloyd Wood 10

Delayed acknowledgements Increased ack delay decreases throughput; window growth in recovery is slowed… for both SACK and New Reno. Similar results were surprising; experience tells us SACK performs better in most scenarios. What happened?

sender receiver sender receiver second segment received − ack sent system timer expires − ack sent receiver using delayed acks receiver without delayed acks segment in transit in packet in network ack in transit in packet in network

FTP transfer over Teledesic using TCP New Reno

short no delacks short 200ms delack short 500ms delack multipath no delacks multipath 200ms delack multipath 500ms delack Amount of file transferred as seen by application (K) x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

FTP transfer over Teledesic using TCP SACK

short no delacks short 200ms delack short 500ms delack multipath no delacks multipath 200ms delack multipath 500ms delack Amount of file transferred as seen by application (K) x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

a. Transfers using New Reno TCP
b. Transfers using SACK TCP

Progress of FTP transfer between terminals at Quito and Tokyo using Teledesic

delayed acks degrading file transfer over multiple LEO paths

SLIDE 11

Internetworking with satellite constellations - Lloyd Wood 11

This is due to a delack implementation decision Should only delay in-order acks at the right edge of the window when nothing is outstanding. SACK can then grow its congestion window faster in recovery than New Reno. This should increases flow performance - needed for multiple paths. TCP performance at its best with ordered flows; this encourages flow-based approach to routing/traffic engineering.

FTP transfer over Teledesic using TCP New Reno

short-200ms-delack short-500ms-delack multipath-50ms-delack multipath-100ms-delack multipath-200ms-up-delack Amount of file transferred as seen by application (K) x1000 x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

FTP transfer over Teledesic using TCP SACK

short-200ms-delack short-500ms-delack multipath-50ms-delack multipath-100ms-delack multipath-200ms-up-delack Amount of file transferred as seen by application (K) x1000 x 103 Time (s) 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 20.0 40.0 60.0 80.0 100.0

a. Transfers using New Reno TCP
b. Transfers using SACK TCP

Progress of FTP transfer between terminals at Quito and Tokyo using Teledesic delacks only take place on packets received at the right edge of the window (RFC2581 SHOULD)

delacks degrading rate of file transfer over LEO obeying RFC2581

SLIDE 12

Internetworking with satellite constellations - Lloyd Wood 12

Multicast in the constellation mesh Took a core-based approach; assume that the constellation is likely to be dealing with small number of users in a group. Satellites move, but terminals are fixed; place a fixed core using linear algebra (vector summation) and have its state inherited by the nearest satellite and passed on over time.

M1 M2 M3 z x c M1 M2 M3 c y

SLIDE 13

Internetworking with satellite constellations - Lloyd Wood 13

Hierarchy of terminals - satellites - core maps nicely to the core-based tree (CBT) hierarchy… Core is a satellite; duplicate in mesh, conserve air interface. …but how does multicast perform?

represent members local clouds of members satellites representing their ground terminals satellite nominated as the core and promoted to the highest level of hierarchy may or may not have terminal members. ground terminals

SLIDE 14

Internetworking with satellite constellations - Lloyd Wood 14

LEO (br oad band Ir idi um ) - delay comp arison o f uni cast and core-based multi cast appro aches to g ro up application s (8 users)

2 0 4 0 6 0 8 0 10 0 12 0 14 0 16 0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 20 21 2 2 2 3 2 4 tim e (ho u rs ) g eo m e tr ic m ea n o f de la y s bet w een a ll u ser s (m s ) u nica s t mu lti cast

LE O (b ro adb and I ri dium ) - de lays experi enced by eigh t users of a m ultica st g rou p ap pl icati on

2 0 4 0 6 0 8 0 10 0 12 0 14 0 16 0 18 0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 14 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4

time (ho urs) pa th propa gation del ay ( m s)

ar ithm etic m ea n ge om etric m ea n harm on ic m e a n

CBT in ISL mesh Simulated movement

f constellation over

the course of 24 hours; measured path delays between all terminals via the core, plotted means. Delay and variation in delay are worse than unicast shortest path, but not far worse… Benefit of capacity saving in links due to duplicating packets at satellites.

SLIDE 15

Internetworking with satellite constellations - Lloyd Wood 15

Capacity saving metrics Chang-Sirbu scaling law says that ratio

f multicast/unicast

hops used is proportional to (group size)0.8 And it holds for the constellation network, too.

Testing the Chuang-Sirbu power law for LE O m ulticasts

0.2 0.4 0.6 0.8 1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 group size - log (N) usag e ratio - log( Lm/L u) LEO broadband Iridium s lope of (num ber of group m em bers N)^0.8

Testing th e C huang -S irbu pow er law for M EO m ulticasts

0.2 0.4 0.6 0.8 1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 group size - log (N) usag e ratio - log( Lm/L u) M EO S pacew ay NGSO slope of (number of group m em bers N)^0.8

Multicast/unicast hop savings at LEO Multicast/unicast hop savings at MEO

SLIDE 16

Internetworking with satellite constellations - Lloyd Wood 16

Also invented a variation on the vector algorithm for star constellations without cross-seam links (not that you’d want to do that - core state moves around). Looked at multicast across rosette (Spaceway NGSO):

M EO (S p ac ewa y N GSO ) - delay s ex perie nce d by four us er s of a core -ba se d multic as t appli ca tion

50 100 150 200 250 300 350 400 450 500 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

tim e (h ou rs ) pa th pr o pag ation de la y (m s )

arithm eti c mean geom etric mean harmonic mean

Delay variation is all over the place, due to handover…

SLIDE 17

Internetworking with satellite constellations - Lloyd Wood 17

Handover in rosettes ascending and descending satellites mean two parts of the ISL mesh can be seen overhead; by multihoming ground terminals we increase reliability, and can also introduce two sets of path delays… Current proposals (e.g. Globalstar) just use this for diversity in the air interface.

descending satellites ascending satellites if using two terminals ground station can communicate with either plane − or both at once planes are locally separate terminal ground

low−delay path low−delay path higher−delay paths air interface diversity in shortest−path routing between different satellites

A B

diversity in air interface

SLIDE 18

Internetworking with satellite constellations - Lloyd Wood 18

But we have to modify the existing geometry

f this proposal slightly to get the delay separation we want.

Examined Motorola’s LEO Celestri proposal.

B A

Modified Celestri satellite network showing available choice of surfaces

unprojected longitude unprojected latitude −180 −150 −120 −90 −60 −30 180 150 120 90 60 30 −90 −60 −30 30 60 90

0a 0b 0c 0d 0e 0f 0g 0h 0i 1a 1b 1c 1d 1e 1f 1g 1h 1i 2a 2b 2c 2d 2e 2f 2g 2h 2i 3a 3b 3c 3d 3e 3f 3g 3h 3i 4a 4b 4c 4d 6a 5g 6i 6h 6g 6f 6e 6d 6c 6b 5f 5i 5h 5b 5e 5d 5c 5a 4i 4h 4g 4f 4e

link created using descending satellite link created using ascending satellite

SLIDE 19

Internetworking with satellite constellations - Lloyd Wood 19

Uncontrolle d highe st-s atellite handover for te rm ina ls of 3 0 degre es sepa rat ion at 0 de gree s la titude a cross m odified C elest ri

0 .01 0 .02 0 .03 0 .04 0 .05 0 .06 0 .07 0 .08 0 .09 0.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 7 1 8 1 9 2 0 2 1 2 2 2 3 tim e (ho urs) to tal path p r op agati on d el a y (sec onds ) unc on t r

ll e d ha nd ove r

Controlled surfac e handover for te rm inals of 30 degrees se parat ion at 0 deg ree s la titude a cross m odified Celes tri

0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0 .1 1 2 3 4 5 6 7 8 9 1 0 1 1 12 13 1 4 1 5 16 17 1 8 1 9 20 21 2 2 2 3 tim e (h our s) to tal pa th p rop agatio n dela y (se con ds) a sce nd in g to d esc en ding as ce ndin g to as cen ding de sce nd in g to d esc en ding d es cen ding to asc en ding

LEO Celestri coverage (single in parts – multihoming limited) Modifying for double surface coverage (lower mask elevation angle by 6º) Single-homed terminals pick the highest visible satellite and flip between surfaces Mujlti-homed terminals stick to a surface and give two sets of delay classes

Testing controlled handover for multihomed terminals

SLIDE 20

Internetworking with satellite constellations - Lloyd Wood 20

c omp ariso n of h and over classes acro ss 0 d eg ree s o f latitude

10 20 30 40 50 60 70 80 90 100 110

1

7

1

6

1

5

1

4

1

3

1

2

1

1

1
9
8
7
6
5
4
3
2
1

1 2 3 4 5 6 7 8 9 1 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 lo ngit udinal separat io n be t w ee n te rmina ls (degr ee s) aver age pa th prop agation delay ex pe ri ence d ( ms )

ter min al (desc ending) to term in al (asce nding) term inal (as cend ing) to term in al (asce nding) ter min al (asce nding) to t erm in a l (desce nding) t erm ina l (desce nding) to t erm ina l (desce nding) unco ntro lled han dove r betw een planes

com paris o n of han do ver classes acros s 30 deg re es o f latitu de

10 20 30 40 50 60 70 80 90 1 00 1 10

1

7

1

6

1

5

1

4

1

3

1

2

1

1

1
9
8
7
6
5
4
3
2
1

1 2 3 4 5 6 7 8 9 1 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 long it udina l s ep ar a ti on be tw ee n te rm inals (d e gree s) a ve rag e pat h prop agat i

n delay e xp eri ence d (m s)

t erminal (de scend in g) to t ermina l (asce nding) te rm inal (a scend ing) to te rm ina l (asce nding) t erminal (as cending ) t o te rm inal (d esce nding) t ermina l (desc end ing) t o term inal (d esce nding) unc on trolled h and over bet ween plane s

co mparison of ha n dover class es acro ss 60 deg re es o f latitu de

10 20 30 40 50 60 70 80 90 100 110

1

7

1

6

1

5

1

4

1

3

1

2

1

1

1
9
8
7
6
5
4
3
2
1

1 2 3 4 5 6 7 8 9 1 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 long it udinal se par ation betwee n te rm i na ls (deg rees ) av er age pa th propagation de lay e xperie nce d ( ms)

termin al (des ce ndi ng) to term in al ( asce nding) te rm inal (ascend ing) to term inal (asc ending) termin al (asce n ding) to t erm ina l (desce nding) t erm ina l (desce nding) to t erm ina l (desce nding) unco ntrolled ha ndove r betw een planes

Reusing our tried and trusted delay evaluation method

Uncontrolled handover falls between two limits. At limits of coverage (60º latitude) effect vanishes.

−180 −150 −120 −90 −60 −30 180 unprojected latitude 150 120 90 60 30 −90 −60 −30 unprojected longitude 90 60 30 fixed A is fixed B moves for each simulation range over which one terminal B is moved

SLIDE 21

Internetworking with satellite constellations - Lloyd Wood 21

C ontrolle d s urfa ce handover betw ee n te rm ina ls of 3 0 degre es separat ion at 0 degrees la tit ude f or Spac ew ay NGSO , showing inc o mplete double surf ace c overage at p lane edg es

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ti me (hou rs) tot al pa t h pro p agation de la y (sec on d s) as cendi n g to a sc ending as ce n d in g to de sc ending des ce n di n g to a sc ending des c end ing to des cending

C ontrolled su rfa ce handover betwe en term ina ls of 30 de gree s sepa ratio n at 0 degre es latitude for m odif ie d Spac ew ay NGS O w it h add ed orbital plane and a djus ted int erplane s pa cing

0 . 05 0.1 0 . 15 0.2 0 . 25 0.3 0 . 35 0.4 1 2 3 4 5 6 7 8 9 1 0 1 1 12 1 3 1 4 1 5 16 17 18 1 9 20 21 22 23 tim e (hour s)

to tal pa th p rop ag a ti on de la y (s eco n ds ) a s cen ding to asc en ding as ce nd in g t o d esc en ding de s cen di ng to asc en ding d es ce nd in g to d esc en ding

At MEO, with Spaceway NGSO...

Some gaps in coverage are visible Lower elevation angle gives dual coverage (but not double surface coverage) Orbital planes are too far apart; multihomed terminals still forced to hand over to other surface Insert an extra plane – classes of delay and service are introduced

SLIDE 22

Internetworking with satellite constellations - Lloyd Wood 22

Architectural considerations Support for IP multicast and IP QoS in the constellation are

desirable. For both of those, we need support for IP routing.

Much work has been done on wireless ATM on the air and ISL interfaces – typically two cells packed in a MAC-layer frame with checksum. MPLS is the logical way to combine IP routing with an ATM infrastructure. Constellation is an autonomous system; this influences routing. Combine BGP, IGP, MPLS, tunnelling and even twice-NAT so that satellites can inherit minimal ‘virtual node’ routing state as they move, while terminals have fixed IP addresses.

SLIDE 23

Internetworking with satellite constellations - Lloyd Wood 23

Achievements #1

Showed the desirability, from viewpoint of delay and delay

variation, of cross-seam links in star constellation networks.

Demonstrated interesting transient effects on traffic in ISLs

due to handover, with implications for moving state.

Showed that TCP multipath performance is sensitive to

delack implementation, and that a flow/traffic engineering approach to routing in the constellation mesh benefits TCP.

Proposed a simple, robust approach to multicast in the

constellation by computing core position; resulting capacity savings obey the Chuang-Sirbu scaling law.

SLIDE 24

Internetworking with satellite constellations - Lloyd Wood 24

Achievements #2

Proposed an architecture for the constellation using MPLS.
Introduced a way of managing delay with handover in

the rosette constellation with ISLs, leading to classes of

service. No previous proposals (M-Star, Celestri, Spaceway

NGSO) permit this, but geometries can be modified to do so.

Showed importance of handover in the constellation for its

effect on end-to-end traffic delays.

Publications – journal and conference papers.
Some software, too.

SLIDE 25

Internetworking with satellite constellations - Lloyd Wood 25

Related publications Two peer-reviewed journal papers Wood, Pavlou, Evans, ‘Effects on TCP of routing strategies in satellite constellations’, IEEE Communications Magazine, March 2001. Wood, Clerget, Andrikopoulos, Pavlou, Dabbous, ‘IP routing issues in satellite constellation networks’, International Journal

f Satellite Communications, January/February 2001.

Two related conference papers Wood, Pavlou, Evans, ‘Managing diversity with handover to provide classes of service in satellite constellation networks’, 19th AIAA ICSSC, Toulouse, April 2001. Wood, Cruickshank, Sun, ‘Supporting group applications via satellite constellations with multicast’, IEE ICT ’98, Edinburgh.

Also ICC ’00 (Andrikopoulos, diffserv), an internet-draft on ARQ, COST contributions...

SLIDE 26

Internetworking with satellite constellations - Lloyd Wood 26

Related software contributions Satellite Visualisation software SaVi Wrote most of the scripts in existence, simulating commercial and idealised constellations based on public

descriptions. Several packaged with SaVi 1.0 release.

Network simulator ns Wrote enhancements to Tom Henderson’s code, including graphical constellation network plot perl scripts; sundry speedups and bugfixes. All for ns 2.1b7. Webpages Widely-referenced teaching resource; various awards.