about reusing subscriber connections

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

Neels Hofmeyr nhofmeyr at sysmocom.de
Fri Mar 10 03:37:39 UTC 2017


Testing with the nano3G, e.g. when sending a large SMS, I see that multiple CM
Service Requests may come in on the same IuCS connection. The code so far
assumed that a CM Service Request would always come in on a fresh,
unauthenticated connection (after iuRelease): the ProcessAccessReQuest FSM
always starts out with establishing identities, authentication, ciphering.

Now I've added code to accept a CM Service Request on an already accepted
connection, by sending back an immediate CM Service Accept without even
invoking the PARQ FSM. But that might not be such a good idea:

I face the same for a Location Updating. A phone may choose to send a periodic
LU on an already open and accepted connection (I guess). So we should allow
that by sending back a LU Accept right away, without another authentication
dance.  But we also want to tell the HLR about the LU. The VLR FSMs may also
have other actions in mind that the MSC doesn't know or care about. So:

To not re-invent the wheel outside of libvlr, I would go on and add a flag to
the LU and PARQ FSMs to indicate that the request is coming in on an already
accepted connection, to jump directly to the post-ciphering FSM state.

But I'd like to hear whether you guys have some thoughts or experience on this.


For the case of the large multi-part SMS, we usually are fast enough in
releasing the conn after each SMS fragment. For the next fragment, another
initialUE message with a CM Service Request starts the PARQ FSM, auth+ciph is
re-established, and the next part goes through. But sometimes the UE has
already started to send another CM Service Request to initiate the next SMS
fragment before it acked the previous one -- meaning that before we get as far
as being done and issuing an iuRelease from the CN, the UE already sends
another fresh CM Service Request on the same conn. That means we don't have to
re-establish auth, quite nice actually. To allow cascades like these, we might
also decide to iuRelease slightly later, giving the UE another second to re-use
the open connection, so that we have less message overhead and use less auth
tuples -- I wouldn't actually give it much more than a second; after about five
seconds, the UE usually does an iuRelease itself.

That sounds sane, but actually https://osmocom.org/issues/1816 holds against
that: when I send USSD requests *from the phone* rapidly without leaving time
to iuRelease, only the first USSD goes through from the UE to the CN. The
second one is never received on the IuCS wire. That would indicate that the
phone expects a conn to close right away from the CN, always. When I wait for
iuRelease before sending another USSD, the MO USSD gets its own conn
established and all is well. This behaves identically for both the femto cell
kinds I have for testing. But, today, seeing multiple CM Service Requests on
the same conn for SMS makes me think that #1816 might be a bug in the USSD
dispatch of my phone. If MO SMS can do CM Service Requests on an already open
conn, why should MO USSD not be able to do the same?

I think in the old, pre-VLR code, we would accept multiple CM Service Requests
on the same conn without problems, because the semantics were "re-entrant",
calling secure_connection() in multiple places, which was skipped when some
flag that we're already authenticated was set. The VLR paradigm is different:
it "locks down" a new conn until that is accepted (authenticated and ciphered,
according to config). Once a conn is accepted, the rest of the code does not
need to bother with asking for securing a connection. So far receiving a CM
Service Request is semantically identical with starting a new conn. That's why
I would explicitly add a parameter to FSM invocation to skip over auth+ciph in
case the conn is already accepted, but still do any HLR actions as needed.

What still bugs me is: when the phone knows that a conn is open, why should it
bother with a CM Service Request, it could just start sending the real meat
right away.


Re-using from the CN side:

In https://osmocom.org/issues/1712#note-7 I noted that the code should not page
when a connection is already open.
https://osmocom.org/issues/1862 asks for not attempting to send USSD from the
CN to the UE when a conn is there but not authenticated/ciphered yet.
When the conn is accepted, we can immediately send the MT messages -- however,
if the conn is there but still busy authenticating, we must neither page nor
can we send messages right away. We should then add an item to the queue of
actions to carry out after a paging response, without dispatching a paging
request; and ensure that the queue is also worked off in case we receive a CM
Service Request or LU Request instead of a Paging Response ... actually, this
might already work, but I should test for it.

P.S.: Also wondering, could it happen that we receive a Paging Response on an
already accepted connection? Wouldn't make much sense, but might be possible to
provoke ;)


Any facts/thoughts on this stuff are welcome.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170310/250f0202/attachment.bin>


More information about the OpenBSC mailing list