PhD viva presentation Centre for Communication Systems ... · Internetworking with satellite constellations PhD viva presentation Centre for Communication Systems Research, University

Internetworking with satellite constellationsPhD viva presentation

Centre for Communication Systems Research, University of Surrey11am, Wednesday, 21 February 2001.

Lloyd Woodhttp://www.ee.surrey.ac.uk/Personal/L.Wood/

work done in the Networks Group,Centre for Communication Systems Research,

University of Surrey.

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 of service with smaller path delay variation.

• Architecture – support IP QoS and multicast using MPLS for a single control plane.


With intersatellite links (ISLs)Satellites aren’t just ‘last hop’.Users don’t need to be in samesatellite footprint as gateway stationfor connectivity.Coverage over remote areas (oceans)where there is no local infrastructurepossible.

Physical delay within space segmenthighly variable but deterministic; dependson where terminals and gateways are, pathbetween them. May not be symmetrical.

Can neglect ground segment.Can model space segment, find delay.

Onboard processing, switching, routingare necessary. It’s a network.

example constellations:Iridium, Teledesic, Spaceway

Without intersatellite linksSatellites are just ‘last hop’.Users need to be in same satellitefootprint as gateway station forconnectivity.Coverage over remote areas (oceans)where there is no local infrastructurenot possible.

Physical delay within space segmenthighly predictable and small; dependsentirely on terminal-satellite-gateway hopsduring passes; likely to be symmetrical.

Delay in ground segment unknown .Resulting total delay unknown .

Onboard processing, switching areoptional. No onboard routing.

example constellations:Globalstar, ICO, Skybridge


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 assumptionsrequired to simulate congestion accurately.)


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

0

−30 30

−60 60

150−150

−9060300−60 −30S

Background map rendered byHans 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

1q1r

1s

1t1u

1v

1w

1x

2a

2b

2c

2d

2e

2f

2g

2h

2i

2j

2k

2l

2m

2n

2o

2p2q

2r

2s2t

2u

2v

2w

2x

3a

3b

3c

3d

3e

3f

3g

3h

3i

3j

3k

3l

3m

3n

3o

3p3q

3r

3s

3t

3u

3v

3w

3x

4a

4b

4c

4d

4e

4f

4g

4h

4i

4j

4k

4l

4m4n

4o4p

4q

4r

4s

4t

4u

4v

4w

4x

5a

5b

5c5d

5e5f

5g5h

5i5j

5k5l

5m5n

5o5p5q

5r

5s

5t

5u

5v

5w

5x

6a6b

6c6d

6e6f

6g6h6i6j6k6l6m6n6o

6p

6q

6r

6s

6t

6u

6v6w

6x

7a7b7c7d7e7f7g7h7i7j7k7l7m7n7o

7p

7q

7r

7s

7t

7u

7v7w

7x

8a8b8c8d8e8f

8g8h

8i8j

8k8l

8m8n

8o

8p

8q

8r

8s

8t

8u8v8w8x

9a9b

9c9d

9e9f

9g9h

9i9j

9k

9l

9m

9n

9o

9p

9q

9r

9s

9t

9u9v9w9x

10a

10b

10c

10d

10e

10f

10g

10h

10i

10j

10k

10l

10m

10n

10o

10p

10q

10r

10s

10t10u10v

10w10x

11a

11b

11c

11d

11e

11f

11g

11h

11i

11j

11k

11l

11m

11n

11o

11p

11q

11r

11s

11t11u

11v

11w

11x

12a

12b

12c

12d

12e

12f

12g

12h

12i

12j

12k

12l

12m

12n

12o

12p

12q 12r

12s

12t12u

12v

12w

N

120

90

0

−30 30

−60 60

150−150

−9060300−60 −30S

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

12x

90

60

0

30

-30

-60

-90

0 30 60 90 120 150 180-30-60-90-120-150-180

unpr

ojec

ted

lati

tude

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

2x3a

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

4f4g

4h

4i

4j

4k

4l

4m

4n

4o

4p

4q

4r 4s

4t

4u

4v

4w

4x5a

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

6f6g

6h

6i

6j

6k

6l

6m

6n

6o

6p

6q

6r 6s

6t

6u

6v

6w

6x7a

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

8f8g

8h

8i

8j

8k

8l

8m

8n

8o

8p

8q

8r 8s

8t

8u

8v

8w

8x9a

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

10f10g

10h

10i

10j

10k

10l

10m

10n

10o

10p

10q

10r 10s

10t

10u

10v

10w

10x11a

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

0

30

-30

-60

-90

0 30 60 90 120 150 180-30-60-90-120-150-180

unpr

ojec

ted

lati

tude


ascending (moving north) and descending (moving south) satellites overlap

2e1e4e 3e

3d2d1d 4d

4c3c2c 1c

4b3b 2b1b

4a3a 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)


‘Twisted Manhattan’ satellite network variant

highest latitude

highest latitude

ascending satellites

descending satellites

orbital plane - constant intraplane ISLs maintained

interplane ISLs - variable length

orbital 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

Sho

rtes

t-pa

th p

ropa

gat

ion

del

ay t

ime

(sec

onds

0

1

2

3

4

5

6

7

8

9

1 0

1 1

1 2

1 3

1 4

0 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

mb

er o

f w

irel

ess

lin

ks

(hop

s) t

rave

rsed

...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:


So, taking path delay further…Del ay b e tween terminals o n th e equ ator acro ss sea med Tel edesic

0

2 0

4 0

6 0

8 0

10 0

12 0

14 0

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 0an gle o f se p ara ti o n in lo n g itud e b etw een t e rm ina ls ( d egrees )

tota

l p

rop

ag

ati

on

de

lay

se

en

acr

os

s n

etw

ork

pa

th (

ms

)

so lid bar is del ay range f ro m max to mi n e rror b ar sh ows o n e sta ndard d eviat io n av era ge 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

0

20

40

60

80

1 00

1 20

1 40

0 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)

tota

l p

rop

ag

ati

on d

ela

y s

een

ov

er n

etw

ork

pa

th (

m

s ol i d b a r is de la 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 io n av e ra ge de lay

Teledesic with and withoutcross-seam links; every lineshows a 24-hour simulation ata given latitude separationbetween terminals.Smaller delays and delayvariation with cross-seam links.Note difference at 0º separation.

unpr

ojec

ted

latit

ude

−180 −150 −120


60

−90 −60 −30 180150120906030

90

30

0

−30

−60

−90

0

fixedrange over which one terminal is moved

angle of separation between terminals


Handover and packets in flight

Star seam is a worst case, butthere are transient spikesin path delay for packetsin flight (subject to what yourimplementation does; could justdrop packets with very hardhandover…) every time yourterminal undergoes a handover.

This has implications formoving networkstate between satellites.If you don’t want to disrupt high-rate traffic,you want small spikes ofno 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

3s x 1011.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

packetdestination

as routing changes...

..travels a longerdistance to

goal.

packet en route

later packets...

...take a shorter route.

3.

1.

2.

to or at this satellite

...take a shorter route.earlier packetsbefore handover...

source elsewherein network


TCP over the constellation mesh

Examined interaction of fast recovery and delayed ackswith multipath routing to simulate load balancing.

TCP’s fixed three-dupack threshold presumes congestion,can’t cope with large amounts of reordering. Raisethat threshold and performance improves.

growthexponential

until loss orthreshold isreached

slow start

avoidancecongestion

one segmentcwnd reduced totimeout

TC

P c

on

ges

tio

n w

ind

ow

(cw

nd

)

fast recoverywindow halvedafter loss

(1/cwnd growth)

linear

time since TCP connection opened0

slowstartthreshold(ssthresh)

single segment sentfast retransmit

congestionavoidance

slow startgrowthlinear

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


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


Delayed acknowledgements

Increased ack delay decreasesthroughput; window growthin recovery is slowed… for bothSACK and New Reno.

Similar resultswere surprising;experiencetells us SACKperforms betterin most scenarios.What happened?

sender receiver sender receiver

second segment received − ack sent

system timer expires − ack sent

receiver using delayed acksreceiver without delayed acks

segment in transit in packet in network ack in transit in packet in network


short no delacks

short 200ms delack

short 500ms delack

multipath no delacks

multipath 200ms delack



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


short no delacks

short 200ms delack

short 500ms delack

multipath no delacks




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


This is due to a delack implementation decision

Should onlydelay in-orderacks at theright edge ofthe windowwhen nothingis outstanding.SACK can thengrow its congestionwindow faster in recovery than New Reno. This shouldincreases flow performance - needed for multiple paths.

TCP performance at its best with ordered flows; thisencourages flow-based approach to routing/traffic engineering.


short-200ms-delack

short-500ms-delack

multipath-50ms-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


short-200ms-delack

short-500ms-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 TCPProgress 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


Multicast in the constellation mesh

Took a core-based approach; assume that the constellationis likely to be dealing with small number of users in a group.

Satellites move, but terminals are fixed; place a fixed coreusing linear algebra (vector summation) and have its stateinherited by the nearest satellite and passed on over time.

M1

M2

M3

z

x

c M1

M2

M3c

y


Hierarchy of terminals - satellites - core maps nicelyto 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 theirground terminals

satellite nominated as the core and promoted to the highest level of hierarchymay or may not have terminal members.

ground terminals


LEO (br oad band Ir idi um ) - de lay com p ar ison o f uni cas t and core-b ased mul ti cas tappro aches to g ro up applica tion s (8 users )

0

2 0

4 0

6 0

8 0

10 0

12 0

14 0

16 0

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 )

geo

me

tric

me

an

of

de

lay

s b

etw

een

all

us

ers

(m

s)

u nica st mu lti cast

LE O (b ro adb and I ri dium ) - de la ys e xpe ri e nc ed by e igh t use rs of a m ul t ic a st g rou p ap pl ic ati on

0

2 0

4 0

6 0

8 0

10 0

12 0

14 0

16 0

18 0

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

t ime (ho urs)

pa

th p

rop

ag

atio

n d

ela

y (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 movementof constellation overthe course of 24 hours;measured path delaysbetween all terminals viathe core, plotted means.Delay and variation indelay are worse thanunicast shortest path,but not far worse…

Benefit of capacity savingin links due to duplicatingpackets at satellites.


Capacity saving metrics

Chang-Sirbu scalinglaw says that ratioof multicast/unicasthops used isproportional to(group size)0.8

And it holds for theconstellation network, too.

T es tin g th e Ch ua n g-Si rbu po we r law for LE O m u lti ca sts

0

0.2

0.4

0.6

0.8

1

1.2

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6

group siz e - log (N)

usa

ge

ra

tio

- l

og(L

m/L

u)

LEO broadband Irid ium

s lope of (num ber o f group m em bers N)^0.8

Te sting th e C hu ang -S irb u pow er la w fo r M EO m ul tic as ts

0

0.2

0.4

0.6

0.8

1

1.2

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6group size - log (N)

usa

ge

ra

tio

- l

og(L

m/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


Also invented a variation on the vector algorithmfor star constellations without cross-seam links (notthat you’d want to do that - core state moves around).

Looked at multicast across rosette (Spaceway NGSO):M EO (S p ac ew a y N GSO ) - delay s ex perie nce d by fou r us er s o f a co re -ba se d m u lt ic as t app li ca tion

0

50

100

150

200

250

300

350

400

450

500

0 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 p

rop

agat

ion

de

lay

(ms

)

arithm eti c mean geom et ric mean harmonic mean

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


Handover in rosettes

ascending anddescending satellitesmean two parts of theISL mesh can beseen overhead;by multihomingground terminalswe increase reliability,and can also introducetwo sets of path delays…

Current proposals (e.g.Globalstar) just use this fordiversity in the air interface.

descendingsatellites

ascendingsatellites

if using two terminals

ground station can communicatewith either plane − or both at once

planes are locally separate

terminalground

low−delay path

low−delay path

higher−delay paths

air interfacediversity inshortest−path routing between different satellites

AB

diversity inair interface


But we have to modify the existing geometryof this proposal slightly to get the delay separation we want.

Examined Motorola’s LEO Celestri proposal.

BA

Modified Celestri satellite network showing available choice of surfaces


unpr

ojec

ted

latit

ude

−180 −150 −120 −90 −60 −30 1801501209060300

−90

−60

−30

0

30

60

90

0a

0b

0c

0d

0e0f

0g

0h

0i

1a

1b

1c

1d

1e

1f

1g

1h

1i 2a

2b

2c

2d

2e2f

2g

2h

2i3a

3b

3c

3d

3e 3f

3g

3h

3i4a

4b

4c

4d

6a

5g

6i

6h

6g

6f6e

6d

6c

6b

5f

5i

5h5b

5e

5d

5c

5a 4i

4h

4g

4f

4e

link created using descending satellitelink created using ascending satellite


Un co ntro lle d h ighe st-s atell i te h an do ver f o r te rm ina ls o f 3 0 d eg re es

sep a rat io n at 0 d e gree s la titu d e a cro ss m odi fied C elest ri

0

0 .01

0 .02

0 .03

0 .04

0 .05

0 .06

0 .07

0 .08

0 .09

0.1

0 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 3tim e (h o urs)

tota

l pa

th p

rop

ag

atio

n d

ela

y (s

ec

onds

)

unc on t ro ll e d ha nd ove r

Co n tro lled sur fac e hand o ver f o r te rm in als o f 30 deg rees se p arat io n at 0 d eg ree s la titud e a cross m o di fied Celes tri

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0 .1

0 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 3tim e (h ou r s)

tota

l pa

th p

rop

aga

tio

n d

ela

y (s

eco

nd

s)

a s ce nd in g to d es c en ding as ce ndin g to as cen ding de sc e nd in g to d es c en ding d es cen ding to as c 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 highestvisible satellite and flip between surfaces

Mujlti-homed terminals stick to a surfaceand give two sets of delay classes

Testing controlled handover for multihomed terminals


c omp ariso n of h and over c lasses acro ss 0 d eg ree s o f la t itude

0

10

20

30

40

50

60

70

80

90

100

110

-17 0

-160

-150

-140

-130

-120

-110

-100

-90

-80

-70

-60

-50

-40

-30

-20

-10 0 1 0 20 30 4 0 5 0 60 7 0 8 0 90

100 11 0120 130 14 01 50160 17 01 80

lo ng it ud ina l separat io n be t w ee n te rmina ls (degr ee s)

ave

rag

e p

ath

pro

pa

ga

tio

n d

ela

y e

xp

eri

enc

ed

(m

s)

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

com p aris o n of han do ver c lasses acros s 30 deg re es o f la t itu de

0

10

20

30

40

50

60

70

80

90

1 00

1 10

-170

-16 0

-150

-140

-130

-120

-11 0

-100

-90

-80

-70

-60

-50

-40

-30

-20

-10 0 10 20 3 0 40 50 60 70 8 0 90

100 11 01 201 301 40150 1 601 701 80

lo n g it ud ina l s ep ar a ti o n b e tw ee n te rm in als (d e g ree s)

ave

rag

e p

ath

pro

pag

ati

on

de

lay

exp

erie

nce

d (

ms)

t ermina l (de scend in g) to t ermina l (asce nding)te rm ina l (a scend ing) to te rm ina l (asce nding)t ermina l (as cending ) t o te rm ina l (d esce nding)t e rmina l (desc end ing) t o term ina l (d esce nding)unc on trol led h and over bet w een p lane s

co m p arison of ha n dover c lass es acro ss 60 deg re es o f la t itu de

0

10

20

30

40

50

60

70

80

90

100

110

-170

-160

-150

-140

-130

-120

-110

-100

-90

-80

-70

-60

-50

-40

-30

-20

-10 0 10 20 30 40 50 60 70 80 90

1 001 10

1 201 301 401 501 60

1 701 80

long it ud ina l se par ation betwee n te rm ina ls (deg rees )

av

era

ge

pa

th p

rop

ag

ati

on

de

lay

ex

pe

rien

ce

d (

ms

)

te rmin al (des ce ndi ng) to te rm in a l ( asce nding)te rm inal (ascend ing) to te rm ina l (asc ending)te rmin al (asce n ding) to t erm ina l (desce nding)t e rm ina l (desce nding) to t erm ina l (desce nding)unco nt rolled 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

unpr

ojec

ted

latit

ude

150120906030

−90

−60

−30


0

90

60

30

0

fixed

A is fixed B moves for each simulation

range over which one terminal B is moved


C ontro l le d s urfa ce handover betw ee n te rm ina ls o f 3 0 degre es separat ion at 0 degrees la tit ude f o r Spac ew ay NGSO , showing

inc o mplete doub le surf ace c overage at p lane edg es

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0 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)

tota

l pa

th p

rop

aga

tion

de

lay

(se

con

ds)

as cendi ng to asc ending as ce nd in g to desc ending des cen di ng to asc ending des c end ing to des cending

C o n tro lled su r fa ce h an do ver be tw e en term ina ls of 30 de gree s sep a ratio n at 0 d eg re es latitu d e fo r m o d if ie d Spac ew ay NG S O w it h

ad d ed o rbi tal p lan e an d a dju s ted in t erplan e s pa cin g

0

0 . 05

0.1

0 . 15

0.2

0 . 25

0.3

0 . 35

0.4

0 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 23tim e (ho ur s)

tota

l p

ath

pro

pa

ga

tio

n d

ela

y (s

eco

nds

)a s cen ding to as c en ding as ce nd in g t o d es c en ding de s cen di ng to asc en ding d es ce nd in g to d es c 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; multihomedterminals still forced to hand over to other surface

Insert an extra plane – classes of delayand service are introduced


Architectural considerations

Support for IP multicast and IP QoS in the constellation aredesirable. For both of those, we need support for IP routing.

Much work has been done on wireless ATM on theair and ISL interfaces – typically two cells packed ina MAC-layer frame with checksum.

MPLS is the logical way to combine IP routing withan ATM infrastructure.

Constellation is an autonomous system; this influences routing.Combine BGP, IGP, MPLS, tunnelling and even twice-NAT sothat satellites can inherit minimal ‘virtual node’ routing stateas they move, while terminals have fixed IP addresses.


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.


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.


Related publicationsTwo peer-reviewed journal papersWood, Pavlou, Evans, ‘Effects on TCP of routing strategiesin satellite constellations’, IEEE Communications Magazine,March 2001.Wood, Clerget, Andrikopoulos, Pavlou, Dabbous, ‘IP routingissues in satellite constellation networks’, International Journalof Satellite Communications, January/February 2001.

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

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


Related software contributions

Satellite Visualisation software SaViWrote most of the scripts in existence, simulatingcommercial and idealised constellations based on publicdescriptions. Several packaged with SaVi 1.0 release.

Network simulator nsWrote enhancements to Tom Henderson’s code,including graphical constellation network plot perl scripts;sundry speedups and bugfixes. All for ns 2.1b7.

WebpagesWidely-referenced teaching resource; various awards.

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

Documents

PhD viva presentation Centre for Communication Systems ... · Internetworking with satellite constellations PhD viva presentation Centre for Communication Systems Research, University