about reusing subscriber connections

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