This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Keith keith at rhizomatica.org
On 03/12/2019 17:20, Harald Welte wrote:
> Hi Oliver, Neels, community,
>
> I had some comments on the D-GSM work that didn't really fit directly to
> the gerrit code review, and I thought I'd post it here.
Hi as well.
I add some short comments inline (disclaimer, I'm not fully up to speed
with the code)
>
> == DNS zone / .msisdn suffix ===
>
> One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue
> it is probably besser to use something that fits within the existing DNS hierarchy
> without contesting IANA's authority on gTLDs.
I'd vote for, if at all possible, not making any link to/dependency on
DNS hierarchy.
> == The use of 'age' vs. absolute timestamp ==
>
> In my original D-GSM idas I always thought we'd send an absolute UTC
> timestamp when a given HLR/MSC has ever seen that subscriber. The idea
> here being that any rural GSM network will have some kind of GNSS
> recevier for clock stability in the BTS anyway, and one can hence assume
> that timestamps are synchronized.
I'd vote for a configurable option or an (abs/rel) flag in the mslookup
request. I would not want this implementation to stall a 1st release though.
>
> The advantage of a relative 'age' is obvious: You don't care about the
> absolute clock value being correct anymore. The potential downside is
> that propagation delay might matter. If you have a rather slow / loaded
> geostationary sattelite link from one village, but a faster terrestrial
> link from another village, the 'age' will be ambiguous while an absolute
> timesetamp wouldn't have that.
It's true, and it's also possible that we might have geographically
close villages, (making cases of fast LAC switching probable) at the
same time as having a satellite link in one of both of these villages.
My personal preference is that the community GSM operator should also
manage (in as much as possible) the terrestrial links and where
possible, ensure existence of those between geographically close
communities, but reality is.. confounding on many levels.
>
> Given that the delays we're talking about are probably all sub-second or
> maybe possible about 1s, it's probably not a problem.
Agreed. I would add, it's my intention that whenever there is this kind
of doubt about the actual location of a MS when an incoming call needs
to be delivered, at the (SIP side) we would simply bridge the call to
both locations anyway, resulting in paging on both villages, and the
first to pick up wins.
> == GSUP keepalives / connection loss detection ==
>
> In the presence of unreliable back-haul mesh between villages, the GSUP
> connection can also not be seen as reliable. We would expect to see TCP
> stalls due to packet loss, etc.
We don't envisage a separation between MSC and HLR over unreliable
back-haul, but I think I'm missing something here. (I still need to
actually implement a local setup and observe)