Consolidation Thread: Xboats in a System

[robject]

This was discussed years ago, but I'm re-opening it since I don't remember the range of conclusions.

GIVENS

* The benefit of a fully-realized Xboat system is its reliability. - Walt Smith, 1998.


CT Traders & Gunboats, pages 8-10.

(p8) it jumps, relays its messages to the station on arrival, and then waits to be picked up by a tender, to be refuelled and sent on its way with a new load of messages. The local station, meanwhile, accepts messages, encodes them, and transmits them to a tender at the edges of the stellar system. Messages brought by the arriving xboat and intended for further down the line are consolidated with the new data and all are sent on to another xboat already fuelled and standing ready to leave. The entire network operates like the pony express - messages are always moving at top speed. Transfer time for messages from one xboat to another can beas short as ten minutes, and is rarely more than an hour.

(p10) High population and high technology star systems can be expected to have up to twelve xboats presentat one time, probably distributed evenly between arriving and departing ships.

(p10) The express boat is also capable of only limited endurance. While it can sustainits crew of one and a passenger for the week it spends in jump space, its power, atmosphere, and food reserves are good for only about three days after break-out.

ASSUMPTIONS

• Xboats (especially where multiple legs join) are best served on a schedule rather than waiting for arrivals. Someone is always arriving...
• It seems to me that a weekly pulse sounds right.
• Tenders seem to work in pairs: one in the source system, and one in a target system. Three shared Xboats allow weekly transits.
  • At any one time, a Tender probably has one or two Xboats for transit, and one spare.
• Every two to three weeks, each Tender is refueled.
• Every X months, each Tender is replaced by a new one, and it is cycled back to the starport (with its Xboats) for service.
• The weekly schedule looks like this:
  • An Xboat arrives within 100D of the mainworld. It relays its messages to the Xboat Station, which transmits an update to all Tenders.
    • Transmission rate is at the Speed of Plot.
  • Within one hour, a designated Tender deploys an Xboat back to the origin system.
  • A designated Tender travels to fetch the Xboat, which I thinkis well within an 0.1 AU service area for the ship.
    • The Xboat is refuelled and recharged.

EXPRESS STATIONS

• Could be at L1, L2, or perhaps the leading or trailing Trojan point.
• This is where surplus Tenders are parked.
  • This allows the service to take one out for maintenance as necessary.
  • Assuming a weekly pulse, then we have up to four active Tenders.
    • So three extra Tenders is no big deal.
      • That third one is for Xboat balancing issues; which see.
    • Scale up as you like.
• This is where surplus XBoats are parked, to a certain point.
  • Assuming a weekly pulse, then we have up to twelve active Xboats.
    • Say two or three extra Xboats per spare Tender.
    • And four more Xboats just hanging around at the station.
    • Anything above that is shipped someplace appropriate (via Tender of course).
  • There's always slack in the system; the IISS over provisions a bit to prevent stalls in the network
  • This allows the service to take one out for maintenance as necessary.

 

[mike wightman]

I think the majority of people underestimate just how many xboats the Imperium actually has...

just remember that according to S:7 they can operate without a crew...

The xboat is a jump robot

 

[Spinward Flow]

So, transmission time is NOT AN ISSUE... TYPICALLY.

This is where we get into the Pony Express™ implementation of what amounts to an interstellar evolution of TCP/IP (Transmission Control Protocol/Interstellar Protocol).

Something that has always been glossed over (pretty mightily, at times ) is ... just how much data can an XBoat transfer ... and how long does it take? In other words, what's the I/O speed for data transmissions? Answer, never specified in publication.

The closest answer we get is the "under seven minutes" citation ... but the circumstances of that "under seven minutes" isn't fleshed out with useful operational details, such as whether that particular (record) instance was essentially "choreographed and staged" or otherwise differed from "normal operations" in any way.

I can easily imagine a circumstance in which an XBoat is prepositioned ready to jump as soon as possible after receiving a relay from an inbound XBoat ... just to break the record. Typical procedures aren't followed in order to enable the FASTEST possible turnaround time. Net result ... under seven minutes from breakout to dispatch. However, in order to achieve that record, a few ... corners ... had to be cut:

• The arriving XBoat hadn't even finished transmitting their entire data load to the Tender.
• As soon as the FIRST complete record bound for the destination was linked through the Tender and transmitted to the outbound XBoat, the outbound XBoat immediately got ready to jump, leaving all other communications bound for the destination "on hold" for the NEXT XBoat to be dispatched.
• The receive, uplink, jump cycle took less than seven minutes to complete a highly orchestrated and staged "test" that does not represent standard operational practices, but which did manage to break (and hold) the record for fastest turnaround time between breakout and jump, carrying information from source, through the intermediate system, to the destination (which is all that mattered for breaking the record).
• If the inbound XBoat is coming from an "end of the line" backwater world with VERY LITTLE outbound communication traffic (so not much data to transmit after breakout) the staging of this record breaking attempt would be even easier.

When you "change the conditions of the test" ... you can achieve results that ought to have been impossible.
And then when you "publicize" that the record has been broken, but not how it was done ... ... people (predictably) leap to the WRONG assumptions (with confidence!) and believe that your Express Network system is far more capable than it actually is.

BUT ALSO NOTE that the time between jumps always seems on the order of an hour or two (e.g. more than seven minutes, less than 4 hours); this is probably a reflection on general flight readiness.

There's ... a problem ... with this interpretation.
That problem is logistical ... how fast a Tender can "turn around" an XBoat for dispatch.

Let's look at it from the point of view of an individual XBoat on the network, first.

1. An XBoat breaks out of jump and IMMEDIATELY begins transmitting a firehose of datastream to the nearest Express Tender.
   • How long of a duration that takes is never specified.
2. While the inbound XBoat is transmitting, a Tender needs to maneuver (because XBoats have no maneuver drives themselves) to dock with and retrieve the inbound XBoat.
3. Once the inbound XBoat has been docked with, it needs to be moved into the hangar bay of the Express Tender.
4. Engineering crew onboard the Express Tender oversee the 16 hours of required, routine maintenance checks performed on jump drives after every jump (the pilot would NOT be considered "qualified" to do this work).
5. After 16 hours of continuous refresh/refurbish/replenishment in the Express Tender's hangar bay, the XBoat has been fully fueled and is ready for deployment.
6. The Tender has maneuvered into a position to undock from the (now outbound) XBoat, outside of any 100D jump shadows that could intercept the anticipated jump trajectory.
7. The outbound XBoat undocks and the Tender maneuvers away (removing the Tender's 100D jump shadow from the list of navigation hazards).
8. The outbound XBoat remains on station, awaiting the completion of an uplink of data and order for dispatch from the Express Tender.
9. Data update transmission from Express Tender to outbound XBoat terminate and a dispatch authorization is given by the Express Tender.
10. The outbound XBoat jumps to a new destination star system.

Turn that around and look at it from a Tender's point of view.
How many XBoats can 1 Express Tender "attend to" at a time, concurrently?

Well, according to the deck plans published in LBB S7 ... 2x XBoats with the hangar bay doors closed (because of dimensions and packing efficiency) ... 4x XBoats with the doors left open (maybe 5x XBoats if you get REALLY creative playing TETRIS).

If we assume that 1 Tender = 2 XBoats being replenished concurrently (with some staggering of the schedule for occupation of the hangar bay), that would mean that a single Tender can manage the recovery, maintenance/replenishment, deployment of 1x XBoat every ~8-10 hours getting cycled through the hangar bay.

It would also be possible for an Express Tender to "dock" with an XBoat using only the Tender's Fuel Probe, refuel an XBoat without bringing the XBoat into the hangar bay and then undock to maneuver away in less than 1 hour (basically, 2 combat rounds = 40 minutes) for a minimum "no maintenance cycle" turnaround time of less than 1 hour for a specific XBoat.

The problem with "no routine maintenance" after jumping is that's the kind of Technical Debt that can build up over time, if it keeps happening (too many times in a row). So the XBoats are going to need to "cycle through the hangar" on the regular after a (limit defined by regulations) certain number of jumps. For simplicity, I'm thinking that 3 jumps "no maintenance after jump" would require a "routine hangar maintenance" cycle before making the 4th jump. This would effectively increase the number of XBoats that can be refueled and dispatched by a single Express Tender on a daily basis. It would certainly help bring down the "maximum wait time" between inbound and outbound to the "less than 4 hours" standard for keeping data moving along the Express Network.

But at that point, you're starting to talk about dispatching 6-8 XBoats per 24 hour "day" per Express Tender.
At 40 tons of jump fuel required (because LBB2.77 drives which don't have jump governors!) per outbound dispatch, that then turns into a fuel transfer rate of 240-320 tons of fuel per 24 hours just to get the XBoats to jump! Problem is, LBB S7 Express Tenders only have 150 tons of fuel onboard!

And that's a problem ... ... because LBB S7 Express Tenders only have 1G maneuver drives and gas giants tend to have "large" 100D radius jump shadow limits. Maneuvering down+up the gravity well of a gas giant could easily take 24 hours, round trip, during which the Express Tender is NOT ON STATION and is unavailable to retrieve, refuel and deploy any XBoats (since the Express Tender is maneuvering inside the jump shadow gravity well to refuel itself).

So after fueling up 3x XBoats for dispatch, a LBB S7 Express Tender is going to have to enter a jump shadow to refuel itself.

The alternative to sending the Express Tender "down the well" to get fuel from a gas giant would be to "bucket brigade" fuel shuttle services via Scout/Couriers (which have 2G drives and can make the round trip faster!).

Assuming a 320 ton "worst case" fuel demand per day, Scout/Couriers (plural) would need to make 9 fuel shuttle deliveries (of 36 tons each, leaving enough for the Scout/Courier to continue maneuvering) in a single 24 hour time span ... just so that 1x Express Tender can remain on station outside the jump shadow, ready and able to retrieve, refuel (and maintain/refurbish) and dispatch up to 8 XBoats within a single 24 hour window.

In other words, the LOGISTICS of keeping all of those plates spinning is QUITE the undertaking!

 

[whartung]

• The Xboat is capable of very targeted jumps, landing within a short travel radius of an Express Boat Tender.
• The Express Tenders are necessarily highly reliable; you know exactly where they will be.
• Thus, delay is entirely dependent on recovery time.

The Express "station" (there must be an express station, the tenders alone cannot do the job) is in solar orbit, and, likely, trailing (or leading) the main world. Close, but not too close, So it's position is always well known.

The XBoat jump is no different from anyone else jump. 168 hours +/- 10%. At Earth orbital velocity (30km/s), thats a 1.8Mkm radius assuming it's "aimed" at the now + 7 days location of the express station. Not a big deal. Since most messaging is transmitted, recovery time isn't critical, it's just helpful. At 1G, 1.8MKm is a 15hr round trip. If you launch an XBoat every 6 hours, you'll need 3 1G tenders to keep up with that traffic (probably at least one more when the boats start clustering).

Outside of specific circumstances, such as planets deep in solar (or gas giant) 100D, causing jump masking, there's no reason to play games with XBoat vectors (i.e. tender accelerating them to destination specific vectors). The destination tenders job is to "catch" the XBoat and make it heave too. That said, there's never really a good reason for a XBoat waypoint to be in a jump masked area.

XBoat jump on a schedule. Planners like schedules, thats how they know when things are due and when they're late. There may be exigent circumstances to require an immediate jump, but its rare. The 32 jump arrival windows messes with all sorts of schedules.

If you sent an XBoat every hour, it's very likely they will arrive out of order. But there's no control over that.

When help is always 2 weeks away, a few hours here or there don't really matter than much.

With XBoats on a schedule, they're much easier to provision. No need to "wait for the next one", we have the 6am boat ready to go. The XBoat station is where the extra XBoats are parked. A surplus is maintained, anything above that is shipped someplace appropriate. There's always slack in the system, when a boat can be 32 hours "late", you got to over provision a bit to prevent stalls in the network. Also makes it much easier to take one out for maintenance as necessary, including maintenance on tenders (all sorts of fun when you're short a tender for week...).

 

[Spinward Flow]

The Express "station" (there must be an express station, the tenders alone cannot do the job)

I've always viewed the Express Tenders as merely one of the links in the chain, rather than the anchor points that the entire endeavor rests upon. What you refer to as a "station" I think of as being a Scout Base (somewhere, in the star system).

When LBB S7 was written (and the Express Tender deck plans formulated), the Express Tender design detailed in that book "seemed reasonable" and there wasn't a good reason to question a lot of the assumptions underpinning it. But in hindsight, there are some details of the Express Tender design parameters that probably ought to be subjected to a refresh (and redesign).

Things like ... how is a 1000 ton J1/1G starship supposed to self-deploy across a 4 parsec gap in the Express Network when it only carries 150 tons of internal fuel? If it can't it's going to have to be build "in-situ" at every world along the Express Network ... which isn't always going to be a reasonable proposition.

It's logistical details like that which have me thinking that if you LBB2.81 standard drives a redesign, still using H/H/H drives (like the original) that it would probably make the most sense to (re)design Express Tenders as 720 ton J2/2G starships, except unstreamlined (LBB5.80 configuration: 7), with internal and external docking capacity (880 tons worth @ J1/1G) which would be capable of hosting up to 800 tons of big craft (which means, essentially up to 8x 100 ton XBoats and/or Scout/Couriers simultaneously) at reduced drive performance. Have a "more modest" internal hangar bay (probably 220 tons for 2x 100 ton big craft) and a larger fuel fraction (to fuel more XBoat dispatches before running out of fuel). Include small craft fighters (and crews) which can do the "legwork" of retrieving and deploying XBoats to minimize the amount of maneuvering that the Express Tender needs to do itself while coordinating with the small craft, allowing the Express Tender to focus more on data communications and station keeping/maintenance work on XBoats.

Same role, but with updated details to better "suit" the mission profile with better logistical support built into the design.
A sort of "do one better" effort, if you will ... while still remaining TL=A for everything.

 

[robject]

Thank you Whartung. I've been reviewing other threads here and I think you've got it.

ref

P

Thread 'How many Xboats?'

Aug 8, 2002

How many Xboats/Xboat tenders does it take to maintain a Xboat route?

• plop101
• Replies: 14
• Forum: Imperial Interstellar Scout Service

 

[robject]

I do wonder if it would help if Xboat jump drives are tuned to high-naval quality. I'll dig through High Guard and see what that is.

Ahhh it's in Traveller5... but it SHOULD be somewhere in CT or MT, since Marc's _Agent of the Imperium_ assumes that navy ships tune themselves to some degree.

T5 Book 2 p112

Constant Time. Time in Jump Space is independent of distance. A ship entering Jump Space remains there for a constant length of time, typically a week (168 hours, plus or minus 10%). A ship in JumpSpace-1 travels about one parsec in about a week. A ship in Jump Space-2 travels about two parsecs in about a week.

The actual time naturally varies: commercial ships expect a variation of Flux * 2 hours; finely tuned jump drives(naval) expect a variation of Flux * 1 hour.

^
That's -5 to +5 hours, by the way, so 163 to 173 hours. Still lots of slop time though.

_Agent_ seems to allow better tuning. But then, that's BCS, and Traveller5's core books only directly deal with ACS.

 

[mike wightman]

I think it is in a MT DGP Q&A with regards to fleet jumps...

 

[whartung]

I think the majority of people underestimate just how many xboats the Imperium actually has...

If you have a 6 hour XBoat schedule (4x a day), you need 31 XBoats per route partner. You need 7x4 just to handle the jump lag, and you need some extra to cover the Jump arrival window and XBoat recovery.

Regina subsector alone has 7 XBoat routes, and you need to double that (one for each way).

So, that's 14 x 31 = 434 XBoats, just for Regina. For the Spinward Marches, the number is over 5600. Thats just to satisfy base traffic, you need more to handle maintenance and outages and such.

 

[robject]

Per Dan "Far Trader" Burns:

...if you have more than two incoming links you have to wait for all of them to arrive before dispatching any of your readied X-boats so they can catch the through x-mail for their respective link.

This is a potential problem, although you could always just mandate return trips being synchronized, rather than ALL ROUTES IN synchronization. It's more doable. It's certainly lazier and still reliable.

 

[Condottiere]

I think it's least cost.

Reliability being more a question of statistics.

 

[robject]

Probably Closer to the Original Concept

Say you have an Xboat Tender at Regina, and it has two Xboats.
Then you have an Xboat Tender at Hefry, also with two Xboats.

1. (+0 weeks) XT1: Sends Xb1 to Hefry.
2. (+1 week) Xb1 arrives at Hefry. One hour later, Xb2 is sent back to Regina.
3. (+2 weeks) Xb2 arrives at Regina. One hour later, Xb3 is sent back to Hefry.
   1. At this point, you'll probably have to rotate in a new Tender with fuel.
4. (+3 weeks) Xb3 arrives at Hefry. One hour later, Xb1 is sent back to Regina.

And so on. Xb4 is held in reserve, just in case. Perhaps the tender in Regina has a spare as well.

Replicate for all links.

Thus if you have, say, four legs converging on Glisten, you're likely to have something close to 12 Xboats in system.

Although the original booklet suggested population and TL plays a part in the number of Xboats, but this is a dependent network so I'm not sure how that can be accurate.

---

 

[robject]

just how much data can an XBoat transfer ... and how long does it take? In other words, what's the I/O speed for data transmissions? Answer, never specified in publication.

Assumed not to be an issue, right? And I bet the "under seven minutes" could always be hand-waved as "a really small diff", for anyone who is worried about data rates on their Xboat's cell plan. And that's "recorded", which means Scouts get into barfights over besting the score.

That problem is logistical ... how fast a Tender can "turn around" an XBoat for dispatch.

Right, and we don't want to do that. We want the returning Xboat prepped and ready far in advance. The received Xboat then goes through whatever checklist it needs to go through. Plus we need a spare handy.

This gives us up to a week for prep time for the arrival -- not that the Scouts need it, I suppose.

How many XBoats can 1 Express Tender "attend to" at a time, concurrently?

That's a useful question. If we haul two Xboats or perhaps three, then we have enough to service a weekly route.
If we're sending Xboats daily, we need one Tender per day, or seven Tenders.
And we might even need more.

If we assume that 1 Tender = 2 XBoats being replenished concurrently (with some staggering of the schedule for occupation of the hangar bay), that would mean that a single Tender can manage the recovery, maintenance/replenishment, deployment of 1x XBoat every ~8-10 hours getting cycled through the hangar bay.

Right. And that model seems most reliable if it serves one incoming and one outgoing Xboat per week, it seems to me.

The problem with "no routine maintenance" after jumping is that's the kind of Technical Debt that can build up over time, if it keeps happening (too many times in a row).

Yep, at some point we switch Tenders, and the operating Tender drags its Xboats in for maintenance, while the new one takes over.

We also have the fuel problem which you mentioned -- which is why Tenders need to be refueled externally... it seems to me. Just a different logistics problem that needs to be solved for every two to three Xboats.

This also seems to support a slower, weekly, model, and the Tenders' "typical" setup would seem to be refueling at the starport.

Hence, Xboat ops seem to be around the mainworld. And typically work like this. And the typical mainworld's 100D is "reasonable".

I have NO IDEA how they work in systems like Zaibon.

 

[Spinward Flow]

Regina subsector alone has 7 XBoat routes

That depends on your interpretation.
If the lines on the hex map are "railroads" where the XBoats ONLY move along the lines on the map, then you would get your (mere) 7 routes.

If the lines on the hex map are "simplified" to represent the Nodes on the Network ... but any node within J4 of any other node will have a direct link (such as Boughene to Kinorb, no need to pit stop at Pixie along the way) then you're going to have WAY MORE than 7 routes in the Regina subsector.

OR ... it could be a mix of both.

• Star systems WITHOUT a scout base on the Express Network ... follow the "railroad to the stars" network model. The ONLY systems they connect to are the DIRECT links as depicted on the map.
• Star systems WITH a scout base (or scout waystation) on the Express Network ... have outbound connections to ALL other systems on the Network that are within J4, so direct connection via lines on the map are not necessary.

This would mean that star systems without a scout base will tend to receive more XBoat inbound traffic than they would otherwise typically send out organically (because receiving from locations that they do not directly send to). This could be utilized logistically to help rotate XBoats and crews through star systems which do not host a scout base. This would also help promote a higher dispatch cadence from those nodes on the Network that do not have a scout base in system, reducing overall lag time for the associated legs of Network.

The logistics for the whole thing starts behaving a lot like Traffic Flow (for obvious reasons), which then becomes it's own discipline.

Yep, at some point we switch Tenders, and the operating Tender drags its Xboats in for maintenance, while the new one takes over.

We also have the fuel problem which you mentioned -- which is why Tenders seem to be rotated frequently as well!

The thing is ... it doesn't add up properly, in logistical terms.

In orbit around ANY world (gas giant or otherwise) ... there are 4 regions of space that are important.

1. Bottom of the gravity well for skimming of fuel
2. 100+D away from the world to be outside the jump shadow
3. Breakout FROM jump for incoming XBoats, 100+D away from the world
4. Dispatch TO jump for outgoing XBoats, 100+D away from the world

Only 2-4 might be "near" to each other, while 1 is going to be "far away" (by definition).

Since gas giants "tend to be larger planets" their 100D jump shadow is "bigger" so maneuvering between 1D and 100D is going to take longer to traverse. The advantage of operating around a "less convenient" gas giant in a star system is the reduced risk of needing to interact with other traffic (so pick some out of the way location to conduct Express Network relay operations).

Conversely, habitable worlds with water oceans (large enough to not make water scarce on planet) have a much smaller 100D jump shadow, making refueling runs "more practical" for Tenders, since they will need to spend less time maneuvering inside of a jump shadow before being able to return to their patrol station outside the jump shadow. The downside is that those Tenders will need to "share space" with other inbound/outbound traffic around that particular fuel source world (which can bring security risks).

The point that I'm getting at is that I'm of the opinion that Express Tenders really ought to have TWO types of support craft assisting their mission tasking.

1. Maneuver Tugs ... intended to "wrangle" XBoats (incoming and outgoing) to reduce the amount of maneuvering that the Express Tenders need to do. Ideally, the Maneuver Tugs would also be armed and capable of operating as "mobile turrets"/fighter escorts to defend against unwanted intrusions without needing to risk the (more) precious Express Tenders in direct combat.
2. Fuel Shuttles ... intended to do the "legwork" of maneuvering through the jump shadow so that the Express Tenders can have better uptime on station (they don't have to "go to the (gravity) well themselves" because they outsource that role). In a pinch, Scout/Couriers can be used as orbital fuel shuttles (although they're far from ideal for the task).

With both of those support services "outsourced" to other craft associated with each Express Tender, the Tender itself turns into more of a "command post" type of operation for supporting the Express Network mission.

 

[robject]

So we have conflicting reports on where an Xboat Station lives.

Traders & Gunboats tends to de-emphasize the stations, relegating them to a communications role.


N-Z has a dedicated and well-thought-out description and therefore seems to have priority. This is in the Imperial Encyclopedia.

Xboat Station: Facility for handling xboats at a star system. At each system served by the xboat network, an express boat station is maintained to handle the message traffic and to manage incoming and outgoing xboats. Usually located near the edge of a star system, the station picks up messages beamed to it by incoming xboats and relays the data to the local world for delivery. Messages destined for worlds farther down the line are transmitted to a waiting xboat which then jumps for the next world in the network. The xboat station contains receiving and retransmission equipment; refueling and support facilities for the local staff and waiting crew are also provided. The xboat station maintains a local office on the system's major world for the acceptance of xboat messages, as well as to handle delivery of the messages to addresses on the world.

**** I can't find the original reference where this text comes from. Anyone?

The problem is "manage incoming and outgoing Xboats". This includes "waiting crew", and that's a problem.

The Xboat has to be able to target the Xboat Station, and I don't think it can.


A-M comes from AD01 (Kinunir) (and AD02 and AD03 and Tarsus) and is a less-developed mention. This is in the Imperial Encyclopedia.

[Express stations are] orbital facilities which service and refuel xboats on their communications runs.

It seems to have been created before the idea of the Xboat Tender.

Nevertheless, together with the Tenders it seems to work better. As an orbital facility (or even an L1, L2, or Trojan facility):

• The Xboat targets the mainworld, which is typically doable.
• The Tenders stick close to the mainworld, which means they can retrieve the Xboats within the 3 day death window.
• The Station and Tenders can therefore both support each other and the Xboats, and the mainworld can support them too.
• The station becomes an asset to the mainworld; presumably therefore defense forces can concentrate here.

 

[Condottiere]

The only other operator of the Express Boat network is the Confederation, being a legacy handover.

There is a (canonical) political decision to let it deteriorate naturally, which I assume means that no more (standard) Express Boats are manufactured within the Confederation, including specific components.

Presumably, they can manufacture spare parts themselves, or maybe, smuggle them in from the Imperium.

However, I doubt a complete jump drive, since it's a customized, budgetted/inflated version (Mongoose Second), since it's too large, and likely noticed if one goes missing.

The Imperium mass produces Express Boats, so they can throw any number against the wall.

And least cost takes mass production into account.

 

[Spinward Flow]

The Xboat has to be able to target the Xboat Station, and I don't think it can.

We also seem to be suffering from everyone's favorite sci fi writing failure ... distance doesn't matter.

Let's take a more familiar example ... the Sol system with Terra in it ... to illustrate my point.

Solar System distances from Earth in light-minutes

object	minutes
Sol	8.3
Mercury	5.1
Venus	2.3
Mars	4.4
Jupiter	35.0
Saturn	70.9
Uranus	151.4
Neptune	241.9

In other words, at light speed, a transmission from Neptune to Terra takes ... over 4 hours.
Uranus to Terra takes over 2.5 hours.
Saturn to Terra takes over 1 hour.

My point being that being on the "extreme outer edge" of a star system's planets introduces a ... network lag ... due to sheer distance that will then impact the overall speed of the entire communications service.

So as a practical matter, I would argue that Uranus (in the Sol system) would probably make for the best candidate for an "outer orbit gas giant" to operate an Express Network node from. It's far enough "out" in the planetary system to be "out of the way" from most inbound/outbound interstellar traffic, while still being "close enough" to Terra (the mainworld) such that communication lag times at light speed are not ridonkulous to the point of absurdity when needing to move time sensitive information up/down the comms link with Terra.

Consequently, this would mean that any Express Tenders would be on station ~100D from Uranus (probably just inside the jump shadow so that they can maintain stationkeeping on reactionless maneuver drive power). A scout base/express station for the organization of crews and support offices would probably be on (or in orbit around) one of the moons of Uranus.

Additionally, Uranus is ~19 AU from Sol ... which then means that Uranus is 18-20 AU from Terra, depending on orbital ephemera. Even at 2G continuous acceleration, it is faster to microjump from Uranus to Terra than it is to make the interplanetary transfer on maneuver drive alone. You really need a 4-6G maneuver drive performance before you can make the transit between Uranus and Terra in less than 7 days. My point being that "personnel transfers" between Uranus and Terra can be done EITHER by Ship's Boat (6G) or Pinnace (5G) or Modular Cutter (4G) or Scout/Courier (J2/2G) in "approximately a week" for the transfer. I figure that there would probably be a few regularized shuttle transfer service craft running an established route between Uranus and Terra, probably using small craft outfitted with small craft cabins for both crew and passengers in order to provide sufficient life support endurance for the multi-day orbital transfer between worlds.

 

[Ekofisk]

**** I can't find the original reference where this text comes from. Anyone?

GURPS Traveller, core rules, library data.

 

[whartung]

If the lines on the hex map are "simplified" to represent the Nodes on the Network ... but any node within J4 of any other node will have a direct link (such as Boughene to Kinorb, no need to pit stop at Pixie along the way) then you're going to have WAY MORE than 7 routes in the Regina subsector.

Then that would be more XBoats.

Pretty sure the Imperium can manage lots and lots of XBoats.

I don't know if its still true, but at one point the US Postal Service was the 3rd largest organization on Earth in terms of man power. That list includes the Chinese Military.

As for the time delay from Neptune to Earth, file that under "who cares". For a message that would normally take 12.8 years to travel, it arrived in 151-185 hours. Another 4 aren't really going to matter. It's really not. We make do every day with things that take days to travel, and are delivered once per day. Vital, critical correspondence. Some days we don't get delivery at ALL! But we manage just fine.

XBoat traffic should be filed under "be grateful you get the message at all".

 

[robject]

Pretty sure the Imperium can manage lots and lots of XBoats.

It can, but even the IISS has budgetary considerations.

Although I wouldn't think they ever feel the pinch.