iuup: Fix Handling of subsequent Initialization msgs

Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.

sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""

sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""

sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""

Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
3 files changed
tree: 946a897c5b0f7f3baf6dc58406107ec22e0dd4b8
  1. contrib/
  2. debian/
  3. doc/
  4. include/
  5. m4/
  6. src/
  7. tapset/
  8. tests/
  9. utils/
  10. .gitignore
  11. .gitreview
  12. .mailmap
  13. configure.ac
  14. COPYING
  15. Doxyfile.codec.in
  16. Doxyfile.coding.in
  17. Doxyfile.core.in
  18. Doxyfile.ctrl.in
  19. Doxyfile.gb.in
  20. Doxyfile.gsm.in
  21. Doxyfile.vty.in
  22. git-version-gen
  23. libosmocodec.pc.in
  24. libosmocoding.pc.in
  25. libosmocore.pc.in
  26. libosmoctrl.pc.in
  27. libosmogb.pc.in
  28. libosmogsm.pc.in
  29. libosmosim.pc.in
  30. libosmousb.pc.in
  31. libosmovty.pc.in
  32. Makefile.am
  33. osmo-release.mk
  34. osmo-release.sh
  35. README.md
  36. TODO-RELEASE
README.md

libosmocore - set of Osmocom core libraries

This repository contains a set of C-language libraries that form the core infrastructure of many Osmocom Open Source Mobile Communications projects.

Historically, a lot of this code was developed as part of the OpenBSC project, but which are of a more generic nature and thus useful to (at least) other programs that we develop in the sphere of Free Software / Open Source mobile communications.

There is no clear scope of it. We simply move all shared code between the various Osmocom projects in this library to avoid code duplication.

The libosmocore.git repository build multiple libraries:

  • libosmocore contains some general-purpose functions like select-loop abstraction, message buffers, timers, linked lists
  • libosmovty contains routines related to the interactive command-line interface called VTY
  • libosmogsm contains definitions and helper code related to GSM protocols
  • libosmoctrl contains a shared implementation of the Osmocom control interface
  • libosmogb contains an implementation of the Gb interface with its NS/BSSGP protocols
  • libosmocodec contains an implementation of GSM voice codecs
  • libosmocoding contains an implementation of GSM channel coding
  • libosmosim contains infrastructure to interface SIM/UICC/USIM cards

Homepage

The official homepage of the project is https://osmocom.org/projects/libosmocore/wiki/Libosmocore

GIT Repository

You can clone from the official libosmocore.git repository using

git clone git://git.osmocom.org/libosmocore.git

There is a cgit interface at https://git.osmocom.org/libosmocore/

Documentation

Doxygen-generated API documentation is generated during the build process, but also available online for each of the sub-libraries at https://ftp.osmocom.org/api/latest/libosmocore/

Mailing List

Discussions related to libosmocore are happening on the openbsc@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/openbsc for subscription options and the list archive.

Please observe the Osmocom Mailing List Rules when posting.

Contributing

Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards

We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details

The current patch queue for libosmocore can be seen at https://gerrit.osmocom.org/#/q/project:libosmocore+status:open