openbsc.git branch sysmocom/iu updated. 0.15.0-559-g4f99890

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/osmocom-commitlog@lists.osmocom.org/.

gitosis at osmocom.org gitosis at osmocom.org
Tue Oct 11 00:58:34 UTC 2016


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)".

The branch, sysmocom/iu has been updated
  discards  20e97facea65eb9b25662a1f43de256940176134 (commit)
       via  4f9989048a5763ddb736730db9b4b3e3ddd4ffb9 (commit)
       via  293ca96757daa25be078af013cae4a37734a8bc5 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (20e97facea65eb9b25662a1f43de256940176134)
            \
             N -- N -- N (4f9989048a5763ddb736730db9b4b3e3ddd4ffb9)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=4f9989048a5763ddb736730db9b4b3e3ddd4ffb9

commit 4f9989048a5763ddb736730db9b4b3e3ddd4ffb9
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Tue Oct 11 02:24:53 2016 +0200

    IuCS: rapidly release connections
    
    Do the same as we do in 2G: release the connection as soon as nothing else
    is pending for a given subscriber.
    
    Before, osmo-cscn would wait for the UE "to get bored" and send an Iu
    release. But the CN should stay lean on connections. Also, 25.413[1] in section
    7, 6th point states:
    "While the Iu release is managed from the CN, the RNC has the capability to
    request the release of all Iu connection resources from the corresponding Iu
    connection."
    So far we did not manage Iu release from osmo-cscn at all.
    
    Use the same mechanism we use in 2G: from msc_release_connection(), just before
    freeing the gsm_subscriber_conn, invoke a CN initiated Iu Release command to
    the UE.
    
    This works around OS#1816 ("USSD only works when IuCS is released", on nano3G),
    because the Iu conn is now released right after every signalling, so that
    typically no two requests will use the same conn.
    
    In iu.h/iu.c, add iu_tx_release(), absorbing almost all of the code from
    ranap_handle_co_iu_rel_req().
    
    Add stub to db_test.c, necessary to build it without linking libiu.
    
    [1] 3GPP TS 25.413 v12.4.0 Release 12 / ETSI TS 125 413 V12.4.0 (2015-04)
    
    Related: OS#1816
    Change-Id: Ic12bd6f3666f6fd42bd6d9fdae1c93abee3b6786

http://cgit.osmocom.org/openbsc/commit/?id=293ca96757daa25be078af013cae4a37734a8bc5

commit 293ca96757daa25be078af013cae4a37734a8bc5
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Tue Oct 11 00:50:05 2016 +0200

    IuCS: don't remove Iu conn until release
    
    Don't remove the gsm_subscriber_connection without an Iu Release.
    
    From the 2G paradigm to close a subscriber connection as soon as nothing else
    is pending, osmo-cscn frequently calls msc_release_connection() to see whether
    a conn has anything pending, or discards it.
    
    In 3G however, we so far don't actively release IuCS connections from the MSC
    side, but wait until the IuCS is released from the UE side. So the conn is
    often discarded even though the IuCS stays open and valid, which confuses the
    situation: before the UE releases a bit later, we would try to page the
    subscriber unsuccessfully, because the UE expects to already be connected.
    
    To first fix the discrepancy of Iu vs. subscr release, never discard
    gsm_subscriber_connections when msc_release_connection() is called.
    
    This creates a "lazy" CN that keeps connections open as long as the UE will
    tolerate. It is really fast in sending many SMS in close succession, but is
    certainly a bad CN design choice: we should rather stay lean on connections.
    
    A subsequent commit will change this, but I decided to keep this commit as a
    reference, for when we'd like to test situations that should re-use an
    established connection.
    
    Change-Id: I012378cfa432d791146db387554ec1909de05297

-----------------------------------------------------------------------

Summary of changes:
 openbsc/include/openbsc/iu.h  |  2 ++
 openbsc/src/libiu/iu.c        | 23 +++++++++++++++++++----
 openbsc/src/libmsc/osmo_msc.c | 12 ++++++++----
 openbsc/tests/db/db_test.c    |  3 +++
 4 files changed, 32 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)



More information about the osmocom-commitlog mailing list