osmo-iuh.git branch sysmocom/ipa_nano3G updated. e5c5fd80e1fa77fc766e43003c35947fe99a0840

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 Sep 27 01:37:35 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 "Osmocom code for Iuh interface".

The branch, sysmocom/ipa_nano3G has been updated
  discards  75a61858d5bdee9afed1be059b45666702dfdda0 (commit)
  discards  bc03eeeee2dc9b330a7775e652d19b269530c5e9 (commit)
       via  e5c5fd80e1fa77fc766e43003c35947fe99a0840 (commit)
       via  8823fc735777e5bc06993845a2ce8c8de5fd090c (commit)
       via  deb302cb613157b4ee439cc803537684f7ec64ab (commit)
       via  56d16886a379270ae4afea9245182b4fa3763e2b (commit)
       via  e6877b1e35fa339b572f2f393a014036047b1ca5 (commit)
       via  74b0565d9f1a7abbd665b8456b7a851e1d47f0a8 (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 (75a61858d5bdee9afed1be059b45666702dfdda0)
            \
             N -- N -- N (e5c5fd80e1fa77fc766e43003c35947fe99a0840)

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/osmo-iuh/commit/?id=e5c5fd80e1fa77fc766e43003c35947fe99a0840

commit e5c5fd80e1fa77fc766e43003c35947fe99a0840
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Mon Sep 26 01:07:19 2016 +0200

    hnbgw: vty conformance: rename iuh 'bind' command to 'local-ip'
    
    The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip',
    'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so
    it makes sense to do this now.
    
    Change-Id: Ifda2653bf58044552a5f1477cd7008dec3fb9100

http://cgit.osmocom.org/osmo-iuh/commit/?id=8823fc735777e5bc06993845a2ce8c8de5fd090c

commit 8823fc735777e5bc06993845a2ce8c8de5fd090c
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Thu Sep 22 19:37:29 2016 +0200

    log: hnbgw: add hnbap UE context allocation info log
    
    Change-Id: Iac0ca948d6e699d984c6e424afe7106dcaf2ab1e

http://cgit.osmocom.org/osmo-iuh/commit/?id=deb302cb613157b4ee439cc803537684f7ec64ab

commit deb302cb613157b4ee439cc803537684f7ec64ab
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Mon Apr 25 15:05:32 2016 +0200

    hnbap: accept UE Register Requests with TMSI and pTMSI
    
    Add the option to allow UE Register Requests with a TMSI identity.
    Add VTY command to enable this option, 'hnbap-allow-tmsi'.
    Add hnbgw_tx_ue_register_acc_tmsi().
    
    HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
    UE registers with only a TMSI, we obviously can't store an IMSI. However, since
    we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
    accept the TMSI registration and carry on as usual. All that is needed for
    proper operation is a valid UE context.
    
    This is aimed at the ip.access nano3G femto cell, as it apparently feeds
    whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
    instead of an IMSI as expected. So far this caused failures and the need to
    make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
    different network), so that UE registration switched back to IMSI. When simply
    accepting the TMSI in osmo-hngw, no problems are apparent in our current code
    state.
    
    For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
    identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
    upon first registration to the network.
    
    Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
    page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
    anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
    does include a page-to-all-HNBs in case the first HNB paging fails. But we must
    be aware that UEs that register by TMSI will simply not have an IMSI recorded
    in the list of UE contexts, so a lookup based on IMSI may fail.
    
    Patch-by: Harald Welte <laforge at gnumonks.org>, me
    Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589

http://cgit.osmocom.org/osmo-iuh/commit/?id=56d16886a379270ae4afea9245182b4fa3763e2b

commit 56d16886a379270ae4afea9245182b4fa3763e2b
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Thu Sep 22 18:06:59 2016 +0200

    hnbgw: UE context: add handling by tmsi identification
    
    To prepare for an upcoming commit that accepts TMSI identification upon UE
    Register Requests:
    
    Add tmsi arg to ue_context_alloc().
    Add ue_context_by_tmsi().
    
    This is aimed at the ip.access nano3G femto cell, as it apparently feeds
    whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
    instead of an IMSI as expected.
    
    See the upcoming commit that enables accepting TMSI identities for further
    detail.
    
    Change-Id: I138458443319cc4cbea5ee7906cf5dd72d582130

http://cgit.osmocom.org/osmo-iuh/commit/?id=e6877b1e35fa339b572f2f393a014036047b1ca5

commit e6877b1e35fa339b572f2f393a014036047b1ca5
Author: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Date:   Mon Sep 26 01:27:55 2016 +0200

    hnbap: add UE Register Reject for pTMSIRAI identity
    
    This is aimed at the ip.access nano3G femto cell, as it apparently feeds
    whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
    instead of an IMSI as expected.
    
    Sending a proper registration reject speeds up the response seen on the UE and
    avoids needless waiting.
    
    See the upcoming commit that enables accepting TMSI identities for further
    detail.
    
    Change-Id: I03b69613e6ddd8a08d9358ffc2f74954c231fd2c

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

Summary of changes:
 include/osmocom/iuh/hnbgw.h |   3 +-
 src/hnbgw.c                 |   5 +-
 src/hnbgw_hnbap.c           | 150 ++++++++++++++++++++++++++++++++++++++++++--
 src/hnbgw_vty.c             |  25 ++++++--
 src/ranap_msg_factory.c     |   5 +-
 5 files changed, 174 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
Osmocom code for Iuh interface



More information about the osmocom-commitlog mailing list