This is another step forward towards a more clear data model where a TBF
always has a MS object (which may be lacking some information, and at a
later point when more information is found, it may actually be a
duplicated MS object and hence one duplicate removed and the TBF moved
to the object being kept).
This helps for instance in removing duplicated information stored in
the TBF which is really per MS, like ms_class, ta, etc. Since there's
always a MS object there's no need to keep a duplicate in both classes
in case there's no MS object.
It can already be seen looking at unit test logging that this kind of
data model already provides better information.
Some unit test parts were needed to adapt to the new model too.
Change-Id: I3cdf4d53e222777d5a2bf4c5aad3a7414105f14c
There's no real need for having different copies of this method in each
children. Furthermore, having the method implemented in the base class
made me shoot my foot while trying to move this to the tbf constructor
(see next commit), so let's simplify this and avoid other people
following into the same issue.
enable_egprs() in tbf.h is moved to be public since it needed (as it was
for the duplicated children mehtods with same name), but anyway it will
be moved to private in next commit.
Change-Id: Id7de060318201a42e51f277f898463f4b9a84eba
Return an interface to the window base class so that the tbf base class
can access the common window methods, such as set_ws(). It will be used
in next commit to get rid of duplicated function enable_egprs in both
dl_tbf and ul_tbf subclasses.
The user of the function can then decide to access more specific
functionaltiites of the window class by static casting it to the
specific direction (which is known by the caller since it operates on a
ul_tbf or a dl_tbf).
Change-Id: Ia2e1decf91be1184668e28297c2126affb9c7ae4
In those cases since a string pointer was passed, it always printed
"single" instead of whatever really was being used, since the string
pointer was not NULL.
Change-Id: Idab7d18e8f519e10fc3df4007634661c46f9256d
In general we want to see explicitly the kind of requested allocation at
the start. The MS class is not needed since it's printed in the previous
log line in any case.
Change-Id: I9eb0a592c15be96da9d140ff373c1afead76b18c
Add support of the second NSVC in the info indication.
Add support to update a previous NS configuration.
Allow to update of a NS-VC while the NSE is still available over the
second.
Depends-on: I917f25ebd1239eae5855d973ced15b93731e33a0 (libosmocore)
Depends-on: I3a0cd305fd73b3cb9ec70246ec15ac70b83e57f2 (libosmocore)
Depends-on: I5a2bb95d05d06d909347e2fb084a446ead888cb3 (libosmocore)
Depends-on: I54f110acc3acccb362f6e554324d08cc42b7c328 (libosmocore)
Depends-on: Ia00753a64b7622a0864341f51ea49b6963543755 (libosmocore)
Depends-on: Ic8f6f8aca10da23a18fab8870be7806065a34b47 (libosmocore)
Depends-on: I5f67e6a9bf4cb322bd169061fee0a528012ed54d (libosmocore)
Change-Id: I589ebaa2a2b7de55b7e4e975d8fd6412dd5f214b
It's expected to receive subsequent INFO.ind messages at run-time,
e.g. when a dynamic TCH/F_TCH/H_PDCH timeslot is switched from
PDCH to TCH/F or TCH/H, osmo-bts would send us INFO.ind with the
updated PDCH slot-mask indicating that this timeslot is disabled.
In gprs_nsvc_create_and_connect(), do not bind() on the received
NSVC address unconditionally - we may already be bound to it.
Instead, return early and keep everything unchanged.
I don't know how the PCU is supposed to handle NSVC address change,
at least the new NS2 library does not handle this internally, nor
it provides any API for that. Let's leave it for later.
Change-Id: I159138e41e147cd30212da548b0ccd3f81d61b4e
Related: I4c3bc883d795e5d1ee5ab175ac03684924692a7c
Fixes: Ib389925cf5c9f18951af6242c31ea70476218e9a
Related: SYS#5108
The code in gprs_nsvc_create_and_connect() stores NSEI there for
no reason, despite it's already stored in struct gprs_ns2_nse.
Change-Id: Ib30152a12384cf0448104a1ee1cfb949f4a27553
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: Ie1829a06b83f69f4cd8256adbf9437388ca3d7e0
Related: SYS#4937, OS#1601
It seems that some gcc versions do not consider the priority of
"C" __attribute__((constructor)) definitions in the same order as
they do C++ static initializers, which are called in the order in which
they appear in the compile unit (source file).
The problem has been observed at least in a
environment based on T2 SDE with GCC 6.3.0 and binutils 2.28.
Let's work around this by making sure the __attribute__((constructor))
function always gets the highest priority value permitted by gcc (101).
Closes: SYS#5093
Change-Id: I65de69a32ac929e6ddd4e58980027f9e76813153
Fixes consistent crash under some specific scenarios explained in
OS#4756.
The crash was caused due to a bug in channel allocator algorithm
incorrectly populating tbf->pdch[] array as a result of mismatching
first_ts and resulting pdch selected slot bitmask.
The issue happens because when allocating a UL TBF in allocator B, the
subset is always further forced into allocating one single TS. As a
result, on that branch several variables are updated, but first_ts was
not.
The field used to be updated in older versions, but a bug was introduced
during code refactoring in commit listed below (31 Jan 2018).
Fixes: 0cc7212cfd
Related: OS#4756
Change-Id: I79596803f7dab6f21b58bfe39c2af65d9c5b39d5
Otherwise the TBFs are kept, and hence PCU will continue reserving resources and
DL data queued will still be sent over the air, despite the MS not
listening anymore on the PDCH.
Change-Id: I4ae1c3706b2ed6e4d271cd16f7cd7f8937b84836
Output of all diag in different lines is really confusing, since the
user reads a timeout ocurred and then later in another line something
like "Downlink ACK was received" while no GSMTAP message shows any ACK.
Change-Id: I6a7d79c16c930f0712bc73b308409ececb1946ba
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Change-Id: Ia0852f9f4395f1248b39363ef90f6f5673b24e2f
Related: SYS#4915
This reverts commit 38aaa10ed4.
It was to early because the frequency hopping wasn't ready to be merged.
Change-Id: Ibf055d5adfd9bffaaf51cb8468c79be597467e0f
Introduce a address_type in the NSVC configuration pass the given
protocol.
The remote_ip is network byte order, the default encoding for in_addr and in6_addr.
Change-Id: If26958d5b584973dca79159cf9e7f3f266519ce9
This is a left-over from an earlier version of [1] that makes
Coverity think that there can be NULL pointer dereference,
even despite we assert(pdch != NULL).
[1] I8adc0cdb1b05a87b4df5d4bc196f6d381283a06f
Change-Id: I3490c38e0c1186dfd2fae63526a05c694547cebb
Fixes: CID#214230
The following test cases verify coding of the hopping parameters:
+ (RR) Immediate Assignment
- TC_pcuif_fh_imm_ass_ul_egprs,
- TC_pcuif_fh_imm_ass_ul,
- TC_pcuif_fh_imm_ass_dl,
+ (RLC/MAC) Packet Uplink/Downlink Assignment:
- TC_pcuif_fh_pkt_ass_ul,
- TC_pcuif_fh_pkt_ass_dl,
all of them pass with this (and the upcoming) change applied.
Change-Id: I8adc0cdb1b05a87b4df5d4bc196f6d381283a06f
Related: SYS#4868, OS#4547
It's quite odd to see that in write_packet_downlink_assignment()
we initialize an 'RlcMacDownlink_t', so then the caller can use
the power of CSN.1 codec to generate the final sequence of bytes
to be transmitted, while in write_packet_uplink_assignment() we
already compose the final RLC/MAC message straight away using
the low-level bitvec API (like bitvec_write_field()).
I guess the reason is that at the time of writing this code, the
CSN.1 codec was not stable enough, so it was safer to generate
the message 'by hand'. This would also explain why we *decode*
the final RLC/MAC message in create_ul_ass() right after encoding.
Rewrite write_packet_uplink_assignment(), so now it initializes
a caller-provided 'RlcMacDownlink_t' structure. Given that it's
allocated on heap using talloc_zero(), do not initialize presence
indicators of fields that are not present in the message.
This would facilitate handling of frequency hopping parameters
in the upcoming changes, in particular we can now introduce a
function that would compose Frequency Parameters IE for both
write_packet_{downlink,uplink}_assignment().
Tested manually by running a GPRS-enabled network, as well as by
running test cases from ttcn3-pcu-test => no regressions observed.
Change-Id: I2850b91e0043cdca8ae7498a5fc727eeedd029b6
Related: SYS#4868, OS#4547
In order to be able to encode frequency hopping parameters, let's
pass a const pointer to 'gprs_rlcmac_pdch' (PDCH slot) directly,
instead of passing all related parameters separately.
Change-Id: I6bccad508f0fdccc4a763211008dd847a9111a8d
Related: SYS#4868, OS#4547
According to 3GPP TS 44.060, section 12.12 "Packet Timing Advance",
the 'TIMING_ADVANCE_VALUE' field is optional, and takes 6 bits
if present. This means that a value that fits in range 0..63
(inclusive) can be encoded (0b111111 == 63).
It's possible that tbf->ta() returns GSM48_TA_INVALID == 220,
so the bitvec API would encode only 6 LSBs of it:
220 & 0b111111 == 28
Let's ensure that the 'TIMING_ADVANCE_VALUE' is present iff
tbf->ta() returns a correct (0 <= x <= 63), and absent otherwise.
Change-Id: I342288ea4ef1e218e5744e9be6a8e528d4e697fa