Good Afternoon,
last week at the sysmocom office Daniel and me continued to work on the
window handling. We have now a proper abstraction that allows us to unit
test the DL and UL window handling. The encode/decode of the RBB is now
compatible to itself.
While doing our manual tests (sending a big enough ICMP echo request)
we noticed that in the alloc algorithm b case the we get a lot of NACKs.
In the same setup (only alloc algorithm is changed) the A algorithm has
no NACKs.
I am now going to re-write the allocation handling. In terms of operation
on the first DL assignment (through the PCH) we can only use a singleslot
but when re-using the TBF we might go for multislot. In case the of UL
handling we could always try to use multislot assignments. Is this
understanding correct?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Good Morning,
we at sysmocom continued to add structure/architecture to the PCU
code and started to systematically test the code (using something
as simple as ICMP ping/reply)
Observations:
* "alloc algorithm b" has little (3kbit/s) more bandwidth than just
using the single slot assignment with CS4. There are also some
open coverity issues about this multi slot code.
* Congestion is badly handled. When using a ping that creates IP
fragments the LLC queue of the TBF gets so long that we expire
half the IP fragments before sending them. This means the MS at
the downlink never receives all the IP fragments of a PING.
We played with the BSVC-FLOW-CONTROL parameters but they don't
have any influence here. We have added counting of queue size
and calculation of the average queue delay to the LLC class.
One option is to drop packages based on the PDU lifetime and the
current queue delay.
$ sudo ping -s 1800 -i 0.1 10.23.42.6
(CS4, alloc-algorithm a) is enough to re-produce this issue.
* RLC V(Q) V(R) handling. It appears that after and before the
refactoring the Received Block Bitmap (RBB) is wrongly encoded. The
encode and decode are not compatible to each other (thanks to the
architecture sysmocom is adding to the code this can now be unit
tested!).
So as soon as we don't receive a frame from the UL. The send window
at the phone and the PCU is going out of sync.
After making changes to the window we have also witnesses that on
a fully received window V(Q) and V(R) were WindowSize away from
each other.
<0005> tbf.cpp:1579 UL DATA TFI=0 received (V(Q)=55 .. V(R)=60)
<0005> tbf.cpp:1624 - BSN 60 storing in window (55..118)
<0005> rlc.cpp:173 - Raising V(R) to 61
<0005> tbf.cpp:1690 - Scheduling Ack/Nack, because 20 frames received.
<0005> encoding.cpp:374 Encoding Ack/Nack for TBF(TFI=0 TLLI=0xfa45049d DIR=UL) (final=0) SSN=61
<0005> encoding.cpp:408 - V(N): "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR" R=Received N=Not-Received
This part might be something we broke but we will try to re-produce
with a unit test.
We will continue to work on unit-testing the RLC window handling if
anyone outside sysmocom interested in getting a more stable PCU?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I have added rate counters to the PCU and noticed that a lot of frames
in the DL are re-sent without there actually being any NACK or
transmission errors. I have also re-produced a "stall" by just using
ping with a big enough data size and a low enough interval (the PCU
appears to transmit the ICMP PING but the MS never gets to send a PONG
packet).
In both cases it could be a scheduling issue (e.g. we don't schedule
the UL Packet ACK/NACK). Is any of you aware of it? I had already
highlighted that the scheduling is not fair. I wonder if we are seeing
starvation (and will re-factor to be able to unit test this).
In terms of scheduling. For the SBA we are already having a reservation
that we try to honor in multiple places. Maybe it is time to extend it
and have more reservations?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hello Andreas,
while looking through the osmo-pcu code to figure out why some
connections stall we had some problems making sense of the elapsed time
calculations in gprs_rlcmac_meas.cpp.
Could you confirm/deny my assumptions about it or explain the idea
behind it?
> gettimeofday(&now_tv, NULL);
> elapsed = ((now_tv.tv_sec - loss_tv->tv_sec) << 7)
> + ((now_tv.tv_usec - loss_tv->tv_usec) << 7) / 1000000;
I assume here you're calculating the duration of the measurement period
so far and since you want to have sub-second accuracy you multiply
everything with 128. Why 128?
Is it becasue it simplifies the throughput calculation?
(tbf->meas.dl_bw_octets/elapsed in gprs_rlcmac_dl_bw())
> if (elapsed < 128)
> return 0;
Is the intention here that the duration of the measurements is supposed
to be one second? So every second these measurements are printed out and
reset?
Regards
Daniel Willmann
--
- Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
my clean-ups are not done but there is a basic structure now that
can be refined. I started to add statistics to the BTS (and then will
add statistics per tbf but they are short lived so one would need to
be quick to see them).
E.g. in tbf_free we are freeing still pending llc_frames and I assume
that these are related to the "Killing pending DL TBF" and others. I
am wondering why:
* there is no indication to the SGSN for dropped frames/octets?
* can't the DL-TBF be re-associated/updated after the assignment
is done again?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I got this log from the pcu while using my E71 (the only sub in this
network).
<0007> gprs_rlcmac_meas.cpp:103 UL RSSI of TLLI=0x88661bc6: -67 dBm
<0002> bts.cpp:945 Got ACK, but UL TBF is gone TLLI=0xe512eba3
<0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / TLLI=0xe512eba3: 0%
<0002> tbf.cpp:668 TBF TFI=0 TLLI=0x88661bc6 T3169 timeout during transsmission
<0002> tbf.cpp:690 - Assignment was on PACCH
<0002> tbf.cpp:694 - No uplink data received yet
So there is an ACK for TLLI=0xe512eba3 but at the same time the tlli
0x88661bc6 is timing out.
PCU->SGSN TLLI=0x88661bc6 Attach Request
SGSN->PCU TLLI=0x88661bc6 Attach Accept (new P-TMSI)
PCU->SGSN TLLI=0xe512eba3 Attach Complete (new TLLI) (6s later)
Now the question is how the PCU should behave. I think the MS is
allowed to change the TLLI (after a P-TMSI assignment) after the
contention resolution is completed. From my reading there is no content
resolution on the UL. My E71 appears to run into a timeout and then
issue a RACH request to send the Attach Complete. I think I have
seen other equipment failing to transmit the Attach Complete at
all.
I think for the SGSN -> PCU side we should generally look things up
by IMSI (there is already a warning in the code), for the MS->PCU
side. I think we should store the old and new TLLI (and then put
new_tlli into tlli once the new one is being used).
comments?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I don't see any print connected to the Uplink TBF request for "Attach
accept" (by MS). At this moment the TLLI has been already updated but UL
TBF still does not exist
(what bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF) returns?). Corresponding
to TS 04.60, 11.2.29 Packet Uplink Assignment possibly may use DL TFI to
address the MS in place of TLLI (we still don't know if it's accepted or
not by MS). Also the uplink FN may be used to find corresponding UL TBF
context (according to Packet Uplink Assignment RRBP field) for UL Packet
Control Ack which contains relevant TLLI. So is it really necessary to
link UL and DL TBFs in the case? ...
Regards,
Vladimir Rolbin
On Wed, Oct 30, 2013 at 1:17 PM, Holger Hans Peter Freyther <
hfreyther(a)sysmocom.de> wrote:
> On Sun, Oct 27, 2013 at 01:33:13PM +0100, Holger Hans Peter Freyther wrote:
>
> Hi,
>
>
> > <0007> gprs_rlcmac_meas.cpp:103 UL RSSI of TLLI=0x88661bc6: -67 dBm
> > <0002> bts.cpp:945 Got ACK, but UL TBF is gone TLLI=0xe512eba3
> > <0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 /
> TLLI=0xe512eba3: 0%
> > <0002> tbf.cpp:668 TBF TFI=0 TLLI=0x88661bc6 T3169 timeout during
> transsmission
> > <0002> tbf.cpp:690 - Assignment was on PACCH
> > <0002> tbf.cpp:694 - No uplink data received yet
>
> this is from a routing area update (with some printf debugging):
>
>
> TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) TLLLI changed......
> 0xb68154e6->0xc782d1de
> <0002> tbf.cpp:1626 TBF(TFI=0 TLLI=0xb68154e6 DIR=DL) changing tlli to
> TLLI=0xc782d1de
> <0002> bts.cpp:941 Got ACK, but UL TBF is gone TLLI=0xc782d1de
> <0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 /
> TLLI=0xc782d1de: 0%
> <0002> tbf.cpp:664 TBF(TFI=0 TLLI=0xb68154e6 DIR=UL) T3169 timeout during
> transsmission
> <0002> tbf.cpp:686 - Assignment was on PACCH
> <0002> tbf.cpp:690 - No uplink data received yet
>
> So the DL TLLI has been changed and then we get an ACK for a UL tbf
> with the new TLLI and can't find it. And run into a timeout.
>
>
> I have applied this change:
>
> diff --git a/src/tbf.cpp b/src/tbf.cpp
> index fac5aaf..19bb83c 100644
> --- a/src/tbf.cpp
> +++ b/src/tbf.cpp
> @@ -1618,6 +1618,17 @@ void gprs_rlcmac_tbf::update_tlli(uint32_t tlli)
> if (tlli == m_tlli)
> return;
>
> + printf("%s TLLLI changed...... 0x%08x->0x%08x\n",
> + tbf_name(this), m_tlli, tlli);
> +
> + if (direction == GPRS_RLCMAC_DL_TBF) {
> + gprs_rlcmac_tbf *ul_tbf;
> + ul_tbf = bts->tbf_by_tlli(m_tlli, GPRS_RLCMAC_UL_TBF);
> +
> + if (ul_tbf)
> + ul_tbf->m_tlli = tlli;
> + }
> +
> #warning "TODO.. find the DL/UL opposite and update the TLLI too"
> LOGP(DRLCMAC, LOGL_NOTICE, "%s changing tlli to TLLI=0x%08x\n",
> tbf_name(this), tlli);
>
>
> and now the "Attach Complete" comes immediately after the Attach Accept.
> I will push something like this but we really need a better way to link
> the DL/UL TBFs together.
>
>
> holger
>
>
> --
> - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Schivelbeiner Str. 5
> * 10439 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
>
>
>
Hi all,
I have continued with my refactorings and mostly done:
* Remove global state (e.g. the global lists for ta, sba, tbf, bts
* Add back-pointers to tbf, trx, pdch which will allow to kill methods
that take trx, ts as parameters.
* Started to use C++ classes and functions.
* Stop poking of internals from other classes areas (gprs_rlcmac_data
is still in front of me and the most hairy part).
I will probably need to spend another 40h on this code to finally
have structure in it. Once this is done I will add counters and
rate counters, improve the VTY inspection... and then I can search
for the actual defects we are experiencing.
While doing the refactorings I noticed that both pcu_l1_if.cpp and
sysmo_sock.cpp have different ways to reset the BTS/PCU state. Both
of them have different issues and are both incomplete. It is the
perfect example where structure would have saved timed and made
the code more reliable at the same time.
I am going to work on gprs_rlcmac_data.cpp and while my refactorings
so far where low risk.. the risk will increase when touching and
structuring the above, e.g. it is hard to judge if the difference in
the code-clones is on purpose or actually a bug. There will be only
one way to find it out though.
I am afraid that I have 52 commits compares to master and I am only
half way done. Review and changing directions will be quite difficult
at this point in time.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
This is the begin of a long march of turning tbf into a C++ class
and properly hiding the secrets inside this implementation instead
of having it spread across various different files.
---
src/gprs_rlcmac.cpp | 1 +
src/gprs_rlcmac.h | 97 --------------------------------------------
src/gprs_rlcmac_meas.cpp | 1 +
src/gprs_rlcmac_sched.cpp | 1 +
src/pcu_l1_if.cpp | 1 +
src/tbf.h | 100 +++++++++++++++++++++++++++++++++++++++++++++-
6 files changed, 103 insertions(+), 98 deletions(-)
diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp
index 6546f8a..3dab44f 100644
--- a/src/gprs_rlcmac.cpp
+++ b/src/gprs_rlcmac.cpp
@@ -22,6 +22,7 @@
#include <gprs_bssgp_pcu.h>
#include <pcu_l1_if.h>
#include <gprs_rlcmac.h>
+#include <tbf.h>
/* 3GPP TS 05.02 Annex B.1 */
diff --git a/src/gprs_rlcmac.h b/src/gprs_rlcmac.h
index 8de7417..6fdf600 100644
--- a/src/gprs_rlcmac.h
+++ b/src/gprs_rlcmac.h
@@ -155,103 +155,6 @@ enum gprs_rlcmac_tbf_direction {
#define GPRS_RLCMAC_FLAG_TO_DL_ASS 7
#define GPRS_RLCMAC_FLAG_TO_MASK 0xf0 /* timeout bits */
-struct gprs_rlcmac_tbf {
- struct llist_head list;
- enum gprs_rlcmac_tbf_state state;
- uint32_t state_flags;
- enum gprs_rlcmac_tbf_direction direction;
- uint8_t tfi;
- uint32_t tlli;
- uint8_t tlli_valid;
- uint8_t trx;
- uint16_t arfcn;
- uint8_t tsc;
- uint8_t first_ts; /* first TS used by TBF */
- uint8_t first_common_ts; /* first TS that the phone can send and
- reveive simultaniously */
- uint8_t control_ts; /* timeslot control messages and polling */
- uint8_t ms_class;
- struct gprs_rlcmac_pdch *pdch[8]; /* list of PDCHs allocated to TBF */
- uint16_t ta;
- uint8_t llc_frame[LLC_MAX_LEN]; /* current DL or UL frame */
- uint16_t llc_index; /* current write/read position of frame */
- uint16_t llc_length; /* len of current DL LLC_frame, 0 == no frame */
- struct llist_head llc_queue; /* queued LLC DL data */
-
- enum gprs_rlcmac_tbf_dl_ass_state dl_ass_state;
- enum gprs_rlcmac_tbf_ul_ass_state ul_ass_state;
- enum gprs_rlcmac_tbf_ul_ack_state ul_ack_state;
-
- enum gprs_rlcmac_tbf_poll_state poll_state;
- uint32_t poll_fn; /* frame number to poll */
-
- uint16_t ws; /* window size */
- uint16_t sns; /* sequence number space */
-
- /* Please note that all variables here will be reset when changing
- * from WAIT RELEASE back to FLOW state (re-use of TBF).
- * All states that need reset must be in this struct, so this is why
- * variables are in both (dl and ul) structs and not outside union.
- */
- union {
- struct {
- uint16_t bsn; /* block sequence number */
- uint16_t v_s; /* send state */
- uint16_t v_a; /* ack state */
- char v_b[RLC_MAX_SNS/2]; /* acknowledge state array */
- int32_t tx_counter; /* count all transmitted blocks */
- char imsi[16]; /* store IMSI for PCH retransmission */
- uint8_t wait_confirm; /* wait for CCCH IMM.ASS cnf */
- } dl;
- struct {
- uint16_t bsn; /* block sequence number */
- uint16_t v_r; /* receive state */
- uint16_t v_q; /* receive window state */
- char v_n[RLC_MAX_SNS/2]; /* receive state array */
- int32_t rx_counter; /* count all received blocks */
- uint8_t n3103; /* N3103 counter */
- uint8_t usf[8]; /* list USFs per PDCH (timeslot) */
- uint8_t contention_resolution_done; /* set after done */
- uint8_t final_ack_sent; /* set if we sent final ack */
- } ul;
- } dir;
- uint8_t rlc_block[RLC_MAX_SNS/2][RLC_MAX_LEN]; /* block history */
- uint8_t rlc_block_len[RLC_MAX_SNS/2]; /* block len of history */
-
- uint8_t n3105; /* N3105 counter */
-
- struct osmo_timer_list timer;
- unsigned int T; /* Txxxx number */
- unsigned int num_T_exp; /* number of consecutive T expirations */
-
- struct osmo_gsm_timer_list gsm_timer;
- unsigned int fT; /* fTxxxx number */
- unsigned int num_fT_exp; /* number of consecutive fT expirations */
-
- struct {
- char imsi[16];
-
- struct timeval dl_bw_tv; /* timestamp for dl bw calculation */
- uint32_t dl_bw_octets; /* number of octets since bw_tv */
-
- struct timeval rssi_tv; /* timestamp for rssi calculation */
- int32_t rssi_sum; /* sum of rssi values */
- int rssi_num; /* number of rssi values added since rssi_tv */
-
- struct timeval dl_loss_tv; /* timestamp for loss calculation */
- uint16_t dl_loss_lost; /* sum of lost packets */
- uint16_t dl_loss_received; /* sum of received packets */
-
- } meas;
-
- uint8_t cs; /* current coding scheme */
-
-#ifdef DEBUG_DIAGRAM
- int diag; /* number where TBF is presented in diagram */
- int diag_new; /* used to format output of new TBF */
-#endif
-};
-
extern struct llist_head gprs_rlcmac_ul_tbfs; /* list of uplink TBFs */
extern struct llist_head gprs_rlcmac_dl_tbfs; /* list of downlink TBFs */
extern struct llist_head gprs_rlcmac_sbas; /* list of single block allocs */
diff --git a/src/gprs_rlcmac_meas.cpp b/src/gprs_rlcmac_meas.cpp
index 75da835..3229795 100644
--- a/src/gprs_rlcmac_meas.cpp
+++ b/src/gprs_rlcmac_meas.cpp
@@ -20,6 +20,7 @@
#include <gprs_rlcmac.h>
#include <gprs_debug.h>
#include <pcu_l1_if.h>
+#include <tbf.h>
#include <string.h>
#include <errno.h>
diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp
index 6290c5d..f3edaac 100644
--- a/src/gprs_rlcmac_sched.cpp
+++ b/src/gprs_rlcmac_sched.cpp
@@ -20,6 +20,7 @@
#include <gprs_bssgp_pcu.h>
#include <gprs_rlcmac.h>
#include <pcu_l1_if.h>
+#include <tbf.h>
uint32_t sched_poll(uint8_t trx, uint8_t ts, uint32_t fn, uint8_t block_nr,
struct gprs_rlcmac_tbf **poll_tbf,
diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp
index 218dc23..47bf740 100644
--- a/src/pcu_l1_if.cpp
+++ b/src/pcu_l1_if.cpp
@@ -37,6 +37,7 @@ extern "C" {
#include <gprs_debug.h>
#include <gprs_bssgp_pcu.h>
#include <pcuif_proto.h>
+#include <tbf.h>
// FIXME: move this, when changed from c++ to c.
extern "C" {
diff --git a/src/tbf.h b/src/tbf.h
index 330eac1..a6dfced 100644
--- a/src/tbf.h
+++ b/src/tbf.h
@@ -18,9 +18,107 @@
#pragma once
+#include "gprs_rlcmac.h"
+
#include <stdint.h>
-struct gprs_rlcmac_bts;
+struct gprs_rlcmac_tbf {
+ struct llist_head list;
+ enum gprs_rlcmac_tbf_state state;
+ uint32_t state_flags;
+ enum gprs_rlcmac_tbf_direction direction;
+ uint8_t tfi;
+ uint32_t tlli;
+ uint8_t tlli_valid;
+ uint8_t trx;
+ uint16_t arfcn;
+ uint8_t tsc;
+ uint8_t first_ts; /* first TS used by TBF */
+ uint8_t first_common_ts; /* first TS that the phone can send and
+ reveive simultaniously */
+ uint8_t control_ts; /* timeslot control messages and polling */
+ uint8_t ms_class;
+ struct gprs_rlcmac_pdch *pdch[8]; /* list of PDCHs allocated to TBF */
+ uint16_t ta;
+ uint8_t llc_frame[LLC_MAX_LEN]; /* current DL or UL frame */
+ uint16_t llc_index; /* current write/read position of frame */
+ uint16_t llc_length; /* len of current DL LLC_frame, 0 == no frame */
+ struct llist_head llc_queue; /* queued LLC DL data */
+
+ enum gprs_rlcmac_tbf_dl_ass_state dl_ass_state;
+ enum gprs_rlcmac_tbf_ul_ass_state ul_ass_state;
+ enum gprs_rlcmac_tbf_ul_ack_state ul_ack_state;
+
+ enum gprs_rlcmac_tbf_poll_state poll_state;
+ uint32_t poll_fn; /* frame number to poll */
+
+ uint16_t ws; /* window size */
+ uint16_t sns; /* sequence number space */
+
+ /* Please note that all variables here will be reset when changing
+ * from WAIT RELEASE back to FLOW state (re-use of TBF).
+ * All states that need reset must be in this struct, so this is why
+ * variables are in both (dl and ul) structs and not outside union.
+ */
+ union {
+ struct {
+ uint16_t bsn; /* block sequence number */
+ uint16_t v_s; /* send state */
+ uint16_t v_a; /* ack state */
+ char v_b[RLC_MAX_SNS/2]; /* acknowledge state array */
+ int32_t tx_counter; /* count all transmitted blocks */
+ char imsi[16]; /* store IMSI for PCH retransmission */
+ uint8_t wait_confirm; /* wait for CCCH IMM.ASS cnf */
+ } dl;
+ struct {
+ uint16_t bsn; /* block sequence number */
+ uint16_t v_r; /* receive state */
+ uint16_t v_q; /* receive window state */
+ char v_n[RLC_MAX_SNS/2]; /* receive state array */
+ int32_t rx_counter; /* count all received blocks */
+ uint8_t n3103; /* N3103 counter */
+ uint8_t usf[8]; /* list USFs per PDCH (timeslot) */
+ uint8_t contention_resolution_done; /* set after done */
+ uint8_t final_ack_sent; /* set if we sent final ack */
+ } ul;
+ } dir;
+ uint8_t rlc_block[RLC_MAX_SNS/2][RLC_MAX_LEN]; /* block history */
+ uint8_t rlc_block_len[RLC_MAX_SNS/2]; /* block len of history */
+
+ uint8_t n3105; /* N3105 counter */
+
+ struct osmo_timer_list timer;
+ unsigned int T; /* Txxxx number */
+ unsigned int num_T_exp; /* number of consecutive T expirations */
+
+ struct osmo_gsm_timer_list gsm_timer;
+ unsigned int fT; /* fTxxxx number */
+ unsigned int num_fT_exp; /* number of consecutive fT expirations */
+
+ struct {
+ char imsi[16];
+
+ struct timeval dl_bw_tv; /* timestamp for dl bw calculation */
+ uint32_t dl_bw_octets; /* number of octets since bw_tv */
+
+ struct timeval rssi_tv; /* timestamp for rssi calculation */
+ int32_t rssi_sum; /* sum of rssi values */
+ int rssi_num; /* number of rssi values added since rssi_tv */
+
+ struct timeval dl_loss_tv; /* timestamp for loss calculation */
+ uint16_t dl_loss_lost; /* sum of lost packets */
+ uint16_t dl_loss_received; /* sum of received packets */
+
+ } meas;
+
+ uint8_t cs; /* current coding scheme */
+
+#ifdef DEBUG_DIAGRAM
+ int diag; /* number where TBF is presented in diagram */
+ int diag_new; /* used to format output of new TBF */
+#endif
+};
+
/* dispatch Unitdata.DL messages */
int tbf_handle(struct gprs_rlcmac_bts *bts,
--
1.8.4.rc3
Good Morning,
sched_poll is doing:
llist_for_each_entry(tbf, &gprs_rlcmac_ul_tbfs, list) {
/* this trx, this ts */
if (tbf->trx_no != trx || tbf->control_ts != ts)
continue;
/* polling for next uplink block */
if (tbf->poll_state == GPRS_RLCMAC_POLL_SCHED
&& tbf->poll_fn == poll_fn)
*poll_tbf = tbf;
if (tbf->ul_ack_state == GPRS_RLCMAC_UL_ACK_SEND_ACK)
*ul_ack_tbf = tbf;
if (tbf->dl_ass_state == GPRS_RLCMAC_DL_ASS_SEND_ASS)
*dl_ass_tbf = tbf;
if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS)
*ul_ass_tbf = tbf;
}
llist_for_each_entry(tbf, &gprs_rlcmac_dl_tbfs, list) {
/* this trx, this ts */
if (tbf->trx_no != trx || tbf->control_ts != ts)
continue;
/* polling for next uplink block */
if (tbf->poll_state == GPRS_RLCMAC_POLL_SCHED
&& tbf->poll_fn == poll_fn)
*poll_tbf = tbf;
if (tbf->dl_ass_state == GPRS_RLCMAC_DL_ASS_SEND_ASS)
*dl_ass_tbf = tbf;
if (tbf->ul_ass_state == GPRS_RLCMAC_UL_ASS_SEND_ASS)
*ul_ass_tbf = tbf;
}
New tbf's will be added to the front (llist_add). Is it on purpose
that the dl_tbfs are preferred over ul_tbfs and that the last of
each tbf's will be found? What is the reasoning for this? What will
collect/catch poll_fn's that are in the past?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
in my refactorings (creating a TBF class and moving code that modifes
the internals into the TBF) I am trying to make gprs_rlcmac_ul_tbfs
and gprs_rlcmac_dl_tbfs private and I notice code like:
if (dir == GPRS_RLCMAC_UL_TBF) {
llist_for_each_entry(tbf, &gprs_rlcmac_ul_tbfs, list) {
if (tbf->state_is_not(GPRS_RLCMAC_RELEASING)
&& tbf->tlli == tlli && tbf->tlli_valid)
return tbf;
}
} else {
llist_for_each_entry(tbf, &gprs_rlcmac_dl_tbfs, list) {
if (tbf->state_is_not(GPRS_RLCMAC_RELEASING)
&& tbf->tlli == tlli)
return tbf;
}
}
llist_for_each_entry(tbf, &gprs_rlcmac_ul_tbfs, list) {
if (tbf->state_is_not(GPRS_RLCMAC_RELEASING)
&& tbf->poll_state == GPRS_RLCMAC_POLL_SCHED
&& tbf->poll_fn == fn && tbf->trx_no == trx
&& tbf->control_ts == ts)
return tbf;
}
llist_for_each_entry(tbf, &gprs_rlcmac_dl_tbfs, list) {
if (tbf->state_is_not(GPRS_RLCMAC_RELEASING)
&& tbf->poll_state == GPRS_RLCMAC_POLL_SCHED
&& tbf->poll_fn == fn && tbf->trx_no == trx
&& tbf->control_ts == ts)
return tbf;
}
In the first code. Why is tlli_valid only checked for the UL TBF
and not the downlink one?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
after the report about the missing usf assignment I started to
refactor the allocation algorithms (remove code duplication, apply
information hiding, directly access things).
Looking at the code it appears that algorithm A and B will always
select the first (in case of A) or the first and following (in case
of B) enabled PDCH.
I have the suspicion that in case of algorithm A only the first
PDCH will be used to assign to phones? And in case of algorithm B
it is likely that the assignments are not spread equally across the
available timeslots?
can someone confirm/deny?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Good Evening,
I started a branch to add a basic structure to the TBF handling. The
reasons why I am doing this is for another lengthy email. I just came
across a piece of code and would like to create some awareness:
int write_immediate_assignment(bitvec * dest, uint8_t downlink, uint8_t ra,
uint32_t ref_fn, uint8_t ta, uint16_t arfcn, uint8_t ts, uint8_t tsc,
uint8_t tfi, uint8_t usf, uint32_t tlli, uint8_t polling,
uint32_t fn, uint8_t single_block, uint8_t alpha, uint8_t gamma,
int8_t ta_idx);
and invocations like:
if (sb)
plen = write_immediate_assignment(immediate_assignment, 0, ra,
Fn, qta >> 2, bts->trx[trx].arfcn, ts,
bts->trx[trx].pdch[ts].tsc, 0, 0, 0, 0, sb_fn, 1,
bts->alpha, bts->gamma, -1);
else
plen = write_immediate_assignment(immediate_assignment, 0, ra,
Fn, tbf->ta, tbf->arfcn, tbf->first_ts, tbf->tsc,
tbf->tfi, tbf->dir.ul.usf[tbf->first_ts], 0, 0, 0, 0,
bts->alpha, bts->gamma, -1);
With the above method and two invocations it is difficult to get all
arguments right and it is a strong argument against ever writing code
like this. With C++ one could create overloads that take the bts and
tbf as parameters. Or if one really only wants to have a single method
use a struct to pass the parameters. This has the benefit of naming
the parameters and will certainly require the same amount of stack
space as the current option.
So please, don't write methods like the above as they make maintaining
the code more difficult than it needs to be.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Dear Ivan, all,
I started to do work on the PCU and didn't compile C++ for a long time.
I was surprised how long it takes to compile the code. From my point
of view we are taking the hit of g++ without really using any of the
features that C++ vould provide (e.g. no stack variables with automatic
cleanup..).
osmo_timer_del is an idempotent operation. There is no requirement
to check if it is running. If you don't want a timer to run, delete
it. Maybe one should have called the method _unschedule, _cancel to
make this more clear.
---
src/gprs_bssgp_pcu.cpp | 6 ++----
src/sysmo_sock.cpp | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp
index 54753b8..c791913 100644
--- a/src/gprs_bssgp_pcu.cpp
+++ b/src/gprs_bssgp_pcu.cpp
@@ -515,8 +515,7 @@ static int nsvc_signal_cb(unsigned int subsys, unsigned int signal,
case S_NS_BLOCK:
if (nsvc_unblocked) {
nsvc_unblocked = 0;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
bvc_sig_reset = 0;
bvc_reset = 0;
bvc_unblocked = 0;
@@ -646,8 +645,7 @@ void gprs_bssgp_destroy(void)
if (!bssgp_nsi)
return;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
osmo_signal_unregister_handler(SS_L_NS, nsvc_signal_cb, NULL);
diff --git a/src/sysmo_sock.cpp b/src/sysmo_sock.cpp
index a4cc6de..d4fb5a6 100644
--- a/src/sysmo_sock.cpp
+++ b/src/sysmo_sock.cpp
@@ -304,8 +304,7 @@ void pcu_l1if_close(void)
if (!state)
return;
- if (osmo_timer_pending(&state->timer))
- osmo_timer_del(&state->timer);
+ osmo_timer_del(&state->timer);
bfd = &state->conn_bfd;
if (bfd->fd > 0)
--
1.8.3.2
Dear Andreas, Ivan,
when trying to understand the CPU usage of the PCU without having
any subscribers I noticed the following backtrace:
#0 _int_malloc (av=0x402fe4d4, bytes=52) at malloc.c:3241
#1 0x4023a3b8 in __GI___libc_malloc (bytes=52) at malloc.c:2859
#2 0x4929b6e8 in _talloc_zero () from /usr/lib/libosmocore.so.4
#3 0x49422e44 in vector_init () from /usr/lib/libosmovty.so.0
#4 0x4941f1f8 in install_element () from /usr/lib/libosmovty.so.0
#5 0x492e602c in gprs_ns_vty_init () from /usr/lib/libosmogb.so.2
#6 0x0001b670 in gprs_bssgp_create (local_port=<optimized out>, sgsn_ip=184194049,
sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=2, bvci=2, mcc=<optimized out>,
mnc=<optimized out>, lac=1, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:585
#7 0x00016990 in pcu_rx_info_ind (info_ind=0x7) at pcu_l1_if.cpp:431
#8 pcu_rx (msg_type=<optimized out>, pcu_prim=0x3) at pcu_l1_if.cpp:577
#9 0x00017914 in pcu_sock_read (bfd=0x6a3f0) at sysmo_sock.cpp:151
#10 pcu_sock_cb (bfd=0x6a3f0, flags=1) at sysmo_sock.cpp:218
#11 0x49294ff4 in osmo_select_main () from /usr/lib/libosmocore.so.4
#12 0x0000a668 in main (argc=<optimized out>, argv=0xbee40b04) at pcu_main.cpp:219
This means when a info indication is received gprs_bssgp_create will
be called which will re-initialize the VTY commands but more important
re-set vty_nsi inside the VTY code of libosmogb. But it also means that
vty_nsi will be a dangling pointer in case of
1.) gprs_ns_nsip_connect, btsctx_alloc, gprs_ns_nsip_listen fail
2.) Between the sysmobts software exiting and re-starting and bringing
OML back up
3.) More cases that I might not understand.
The dangling pointer will lead to a crash when the VTY of the PCU is
used in such situation/window.
does any of you care to fix that race? I think the easiest would be
to just close/open/bind/listen/connect on the NS once we get a new
config.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
hi ivan,
there is still one patch left in my jolly/meas branch that has not been
mergen:
commit 890ae7e4fcf7d74c238ed2ce0e3f090f1af492c2
and the fixup:
commit 784f9004ba3576ede57dada63876451f32d2d852
it keeps the timing advance from a TBF and uses it for new TBFs, so the
mobile can be at any distance. this was tested up to 4 km (with sysmobts).
if it is ok, i will combine these patches and push the result to master.
regards,
andreas
Dear Ivan,
it appears to that starting from your configure.ac change the vty tests
can not be eanbled anymore. E.g. compare this with the build results on
the jenkins after your change.
do you have time to fix that today?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
From: Holger Hans Peter Freyther <zecke(a)selfish.org>
Make the code handle SIGTERM. This way the pcu can be easily stopped
with a sysvinit script.
---
src/pcu_main.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index f135cfd..4fae14b 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -114,6 +114,7 @@ void sighandler(int sigset)
switch (sigset) {
case SIGINT:
+ case SIGTERM:
/* If another signal is received afterwards, the program
* is terminated without finishing shutdown process.
*/
--
1.7.10.4
hi,
steve and me experienced a problem with dissecting a "packet resource
request" at pcu. the patch i attached will show the following output:
$ make && src/osmo-pcu
PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
Exist_ACCESS_TYPE = 1 | ACCESS_TYPE = 3 | : ID | Choice
PacketResourceRequestID = 1 | u.TLLI = 0x7ee0e8fd | : End ID |
Exist_MS_Radio_Access_capability = 1 | : MS_Radio_Access_capability |
MS_RA_capability_value { | Choice MS_RA_capability_value_Choice = 1 |
u.Content length = 34 | RF_Power_Capability = 4 | Exist_A5_bits = 1 |
A5_bits = 96 | ES_IND = 1 | PS = 0 | VGCS = 0 | VBS = 0 |
Exist_Multislot_capability = 1 | : Multislot_capability |
Exist_HSCSD_multislot_class = 0 | Exist_GPRS_multislot_class = 1 |
GPRS_multislot_class = 10 ....
this is all correct, but then i patched the get_ms_class_by_capability()
function at grps_rlcmac_data.c:
...
printf("we have = %d\n", cap->Count_MS_RA_capability_value);
for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech);
printf("exists multislot capability %d\n",
cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability);
printf("exists class %d\n",
cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class);
printf("class %d\n",
cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class);
...
the output continues as this:
we have = 2
index=2
exists multislot capability 0
exists class 1
class 10
index=0
exists multislot capability 0
exists class 0
class 0
the "class 10" is correct, also it is correct that the class only exists
in the first entry of the capability array. the output of the dissector
states that multislot capability exists (Exist_Multislot_capability =
1), but if i look at the structure, this field is not set.
i looked at the dissector code, but don't really understand why
CSN_NEXT_EXIST works for some elements and not for others.
any ideas?
regards,
andreas
Dear fellow Osmcoom developers,
it is my pleasure to finally announce the date + venue of OsmoDevCon
2013:
Date: April 04 through April 07, 2013
Place: IN-Berlin, Lehrter Str. 53, Berlin
Like last year, this is an event for developers of the various Osmocom
proejects. Reservation and confirmation of reservation is required.
The event is free of charge. The Room is made available by IN-Berlin
e.V., an Internet related non-profit organization. Lunch catering will
be sponsored (so far by sysmocom GmbH, but if any other sponsors come
up, we are happy to share the cost).
So all you have to cover is your own travel + accomodation costs, as
well as breakfast and dinner. If you are an active developer and cannot
afford travel/accomodation, please let me know and I'll see if we can do
something about it.
If you would like to attend, please send a message to
laforge(a)gnumonks.org applying for registration of the event. The
registration deadline is March 5, i.e. one week from now.
There is no detailed schedule of talks yet. I will start a separate
discussion suggesting / collecting topics in the next couple of days.
More information is (and will be made) available at
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2013
Further discussion regarding the event should be directed at the
osmocom-event-orga(a)lists.osmocom.org mailing list, to avoid
cross-posting over the various project-specific lists.
Best regards and happy hacking,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
I noticed a bug in the dissector, which seems to happen when then
Exist_A5_bits field is set to 0, and results in the following fields
(Exist_Multislot_capability/Exist_GPRS_multislot_class) being decoded
incorrectly. Thus, get_ms_class_by_capability() is returning NULL
instead of the GPRS_multislot_class, which is interestingly dissected
correctly.
This is one of the messages where this happens:
4017dfb83a3f628a7045500898f28109100297e0080b2b
If I add it to the RLCMACTest it fails, so I propose it should be added
;)
My quite recent version of Wireshark (1.8.2) is decoding this message
fine, see the attachment. I've gone through the recent changes on
packet-gsm_rlcmac.c and packet-csn1.c in Wireshark, but couldn't spot
the commit that fixed it so far.
Regards,
Steve
Hi all,
one of the problems when debugging PCU issues is: How to take proper
logs on-site where a problem shows up and give them back to the
developer(s) for analysis. If you capture the PCU stdout or configure
file-based logging, you will have a hard time corellating that with PCAP
traces taken on the RLC/MAC side and/or on the Gb side.
Therefore I propose a new idea here and would like to get your review:
What about implementing a "GSMTAP" log target for libosmocore? This way
we could encapsulate the log messages into a special GSMTAP message,
which would be sent synchronously in the GSMTAP stream together with
RLC/MAC messages on the lower end.
The same could in fact be utilized in osmo-bts, too. This way we could
capture BTS log/debug output in-order to L1 messages that we receive and
transmit.
What do you think about it? I would be willing to draft the GSMTAP
sub-header format and write + submit the wireshark dissector, if
somebody wants to write libosmocore log target.
Ideally we would log _all_ messages to that target, and include the
subsystem and log level in a header field, so the log verbosity could
still be adjusted at the point of review, instead only at the time of
logging.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
the default build is broken since the 17th of october. Anynone
feels responsible to fix it after the merge?
Build results can be seen here[1]. It probably has to with enabling
sysmobts support but not direct PDCH queue access.
holger
[1] http://jenkins.osmocom.org/jenkins/job/osmo-pcu/label=linux_i386_debian_squ…
Dear all,
it is a pity to see that since many weeks there has been no progress on
merging any of Andreas' work. I think everyone involved is to be
blamed to some extent. Andreas because the provided branches are not
kept clean, Ivan probably for lack of time, and me for not paying more
attention and helping this process along.
The general life-cycle in any project, including osmo-pcu, should be as
follows:
* contributor starts on some improvements, creates private branch
* master advances meanwhile
* contributor rebases (not merges!) his changes on top of more recent
master
* contributor indicates that his branch is ready for merge
* maintainer merges (some of?) the commits of the contributor branch
* contributor re-bases remaining commits on new master
* contributor requests merge of remaing patches
...
If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I
get grey hair (to say the least). One would normally expect:
1) 'jolly' to be based on some (maybe not current) master
2) 'jolly_dsp' to be based on 'jolly'
Neither of the two is the case. I've tried to
* rebase jolly on top of master
as well as
* rebase jolly_dsp on top of jolly
and both are impossible due to the series of merges and the unclear
ancestry / relationship of the branches. Or, just for fun, try 'git
diff origin/jolly..origin/jolly_dsp. It shows you anything else but
what one would expect
Andreas: Please take some time to clean up the mess. Your 'jolly'
branch should contain a series of clean per-feature commit's on top of
current master, and 'jolly_dsp' should be a set of few patches on top of
'jolly'.
This way there is always a clean queue of changesets that Ivan can merge
(or cherry-pick). I can understand that if I was in Ivan's place, I
would not really know where to even start merging some of those
contributions.
Thanks for everyone's attention. Please take some time to get this
resolved. Let me know if you have some questions. There are plenty of
people with lots of git experience around (Holger, Pablo, myself) who
can help if something is unclear.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
while running osmo-pcu, it appears that it is leaking memory. At
startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2),
while after about 8MBytes of data transfer of a single GPRS-MS over 48
hours, the virtual size has expanded to 8584 kBytes.
Now I know that VSS is not RSS, etc. - but the fact that it always only
increasees, and increases with traffic is a clear indication of some
leakage somewehere.
Unfortunately it also seems talloc is not used correctly in osmo-pcu, as
a USR1 signal doesn't really show any allocated objects beyond two. So
somehow either not all allocations are done with talloc, or the
allocation hierarchy does not link the objects to the root talloc
context.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Not sure if this is expected or not, I thought it might be useful to
report it here:
<0001> pcu_l1_if.cpp:295 RACH request received: sapi=1 qta=2, ra=121, fn=12615
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for DL TBF=1
<0005> gprs_rlcmac_data.cpp:872 Got RACH from TLLI=0xc65c8728 while DL TBF=1 still exists. Killing pending DL TBF
<0002> gprs_rlcmac.cpp:905 Software error: Pending downlink assignment. This may not happen, because the assignment message never gets transmitted. Please be shure not to free in this state. PLEASE FIX!
This is a single BTS with a single GPRS-capable MS, using TS6+TS7 for
PDCH
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi,
i get wrong decoding of RLCMAC control block.
the decoder of osmo-pcu is decoding following sequence:
0x40,0x16,0x76,0x67,0x74,0x02,0x26,0x64,0xe8,0x65,0x64,0x69,0x00,0x3e,0x4c,0x00,0x2b,0x2b,0x2b,0x2b,0x2b,0x2b,0x2
this is the result:
PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
Exist_ACCESS_TYPE = 1 | ACCESS_TYPE = 0 | : ID | Choice
PacketResourceRequestID = 1 | u.TLLI = 0xd99dd008 | : End ID |
Exist_MS_Radio_Access_capability = 1 | : MS_Radio_Access_capability |
MS_RA_capability_value[0] { | Choice MS_RA_capability_value_Choice = 3 |
u.Content length = 25
... at this point, the length of the content is 25 bits:
| RF_Power_Capability = 1 | Exist_A5_bits = 1 | A5_bits = 80 | ES_IND =
1 | PS = 1 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 | :
Multislot_capability | Exist_HSCSD_multislot_class = 0 |
Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 12 |
GPRS_Extended_Dynamic_Allocation_Capability = 1 | Exist_SM = 0
... at this point all 25 bits are decoded, so the decoder must abort
decoding of content of Multislot_capability_t (see gsm_rlcmac.cpp).
instead, it continues with the data found after these 25 bits: (all crap
from now on)
| Exist_ECSD_multislot_class = 0 | Exist_EGPRS_multislot_class = 0 |
Exist_DTM_GPRS_multislot_class = 1 | DTM_GPRS_multislot_class = 2 |
Single_Slot_DTM = 1 | : DTM_EGPRS_Params |
Exist_DTM_EGPRS_multislot_class = 0 | : End DTM_EGPRS_Params | : End
Multislot_capability | Exist_Eight_PSK_Power_Capability = 0 |
COMPACT_Interference_Measurement_Capability = 1 |
Revision_Level_Indicator = 0 |
UMTS_FDD_Radio_Access_Technology_Capability = 0 |
UMTS_384_TDD_Radio_Access_Technology_Capability = 0 |
CDMA2000_Radio_Access_Technology_Capability = 0 |
UMTS_128_TDD_Radio_Access_Technology_Capability = 0 |
GERAN_Feature_Package_1 = 0 | Exist_Extended_DTM_multislot_class = 0 |
Modulation_based_multislot_class_support = 0 |
Exist_HighMultislotCapability = 0 | Exist_GERAN_lu_ModeCapability = 0 |
GMSK_MultislotPowerProfile = 3 | EightPSK_MultislotProfile = 3 |
MultipleTBF_Capability = 1 | DownlinkAdvancedReceiverPerformance = 0 |
ExtendedRLC_MAC_ControlMessageSegmentionsCapability = 1 |
DTM_EnhancementsCapability = 0 | Exist_DTM_GPRS_HighMultislotClass = 0 |
PS_HandoverCapability = 1 | MS_RA_capability_value[0] } |
MS_RA_capability_value[0] { | Choice MS_RA_capability_value_Choice = 0 |
u.Content length = 0 | RF_Power_Capability = 2 | Exist_A5_bits = 1 |
A5_bits = 50 | ES_IND = 1 | PS = 0 | VGCS = 1 | VBS = 1 |
Exist_Multislot_capability = 0 | Exist_Eight_PSK_Power_Capability = 0 |
COMPACT_Interference_Measurement_Capability = 1 |
Revision_Level_Indicator = 0 |
UMTS_FDD_Radio_Access_Technology_Capability = 1 |
UMTS_384_TDD_Radio_Access_Technology_Capability = 0 |
CDMA2000_Radio_Access_Technology_Capability = 1 |
UMTS_128_TDD_Radio_Access_Technology_Capability = 1 |
GERAN_Feature_Package_1 = 0 | Exist_Extended_DTM_multislot_class = 0 |
Modulation_based_multislot_class_support = 1 |
Exist_HighMultislotCapability = 0 | Exist_GERAN_lu_ModeCapability = 1 |
GERAN_lu_ModeCapability = 6 | GMSK_MultislotPowerProfile = 1 |
EightPSK_MultislotProfile = 1 | MultipleTBF_Capability = 0 |
DownlinkAdvancedReceiverPerformance = 3 |
ExtendedRLC_MAC_ControlMessageSegmentionsCapability = 0 |
DTM_EnhancementsCapability = 0 | Exist_DTM_GPRS_HighMultislotClass = 1 |
DTM_GPRS_HighMultislotClass = 2 | : DTM_EGPRS_HighMultislotClass |
Exist_DTM_EGPRS_HighMultislotClass = 1 | : End
DTM_EGPRS_HighMultislotClass | : End MS_Radio_Access_capability |
there are two problems with the decoder:
- it does not check if the length has been exceeded while decoding
Multislot_capability_t content. if the length is lower than all elements
in Multislot_capabilit_t, the decoder must abort decoding the content.
this is no bug. (the definition used at that point should be
M_NEXT_EXIST_OR_NULL instead of M_NEXT_EXIST, see gsm_rlcmac.cpp)
- even if the correct definition is used, the csn1 decoder will not use
the length given at "u.Content length" to abort. instead it checks for
reaching total length of coded data.
i played a bit with the code, but could not fix it without breaking
other things. but decoding with wireshark works. would it be possible to
port latest wireshark code?
regards,
andreas
hi,
just experiences some problems with my jolly branch (osmo-pcu):
commit e6228b34a75efcb6b0700ac29672d62539860fbf
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Tue Jul 3 13:36:03 2012 +0200
TBF acknowledged mode finished for both link directions
commit c7e7f6868b6f24346424dee904f4e76d3f216ff4
Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com>
Date: Fri Jun 29 22:53:15 2012 +0400
Implemented Paging procedure on CCCH.
Added functions:
- gprs_bssgp_pcu_rx_paging_ps() for handling paging message from BSSGP;
- write_paging_request() for writing paging request message;
- gprs_rlcmac_paging_request() and pcu_l1if_tx_pch() for sending
paging request message to BTS.
the lower commit adds paging procedure, but if i diff between these
commits, i see that my upper commit removes the paging procedure. but i
don't see it, if i "git show e6228b...". any ideas?
regards,
andreas
Hi,
please check jenkins.osmocom.org for details. In general it is a good
idea to subscribe to the RSS log of build failures.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
hi,
i like to announce that multislot supports has been finished and is
working well.
it supports all classes, but i could not test other classes than
semi-duplex class 12. the algorithm allocates as many downlink slots as
allowed by class and as avaiable. it will only allocate a single uplink
slot. there is no dynamic dl/up allocation depending on traffic.
the code is located at osmo-pcu: jolly branch: git log 4b470ffe
regards,
andreas
Hi,
this is not meant as an intensive review on memory allocations
in the PCU code. While browsing the code of the ready-to-send
method to select the next payload I noticed the code below:
RlcMacDownlink_t * mac_control_block = (RlcMacDownlink_t *)malloc(sizeof(RlcMacDownlink_t));
LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ TX : Packet Paging Request +++++++++++++++++++++++++\n");
decode_gsm_rlcmac_downlink(pag_vec, mac_control_block);
LOGPC(DCSN1, LOGL_NOTICE, "\n");
LOGP(DRLCMAC, LOGL_DEBUG, "------------------------- TX : Packet Paging Request -------------------------\n");
bitvec_free(pag_vec);
This and other all other places really should use talloc to make finding
memory leaks more easy (e.g. by printing the leak report), the second part
is that we appear to leak this on every paging message sent by the PCU and
the third is actually a question. Should we use a GCC extension that
helps dealing with local variables? GCC can call a cleanup function
on exit of the scope, an example can be seen here[1] nad this[2] is
the description of the feature.
holger
[1] https://mail.gnome.org/archives/gtk-devel-list/2011-November/msg00050.html
[2] http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attribu…
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
one more email for tonight. Using clang/smatch from time to time
can highlight certain issues. The easiest way to invoke it is this:
$ make CC="clang --analyze" CXX="clang++ --analyze"
1.)
gprs_bssgp_pcu.cpp:241:6: warning: Access to field 'state' results in a dereference of a null pointer (loaded from variable 'bctx')
if (bctx->state & BVC_S_BLOCKED && pdu_type != BSSGP_PDUT_STATUS)
^~~~
the handling of bctx is a bit weird, in theory it can be NULL but
I am not sure if we are likely to receive the messages that would
make the PCU crash though. gprs_bssgp_pcu_rcvmsg can call the above
function/line with a NULL bctx.
2.)
gprs_rlcmac.cpp:728:25: warning: Assigned value is garbage or undefined
tbf->dir.ul.usf[ts] = usf[ts];
^ ~~~~~~~
Probably true, alloc_algorithm_b is really too big to be readable to
verify that this is not a false positive.
cheers
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Holger Hans Peter Freyther wrote:
> in the above it is possible that !poll_tbf and usf == 0x7, is this the
> right behavior in case no TBF could be found?
hi holger,
if poll_tbf is set, we must use an unassigned usf, because only the
polled mobile may transmit. (usf 7 is never assigned.) if poll_tbf is
not set and if no uplink ressource is required, i use usf 7 (any other
usf would also be ok, since we don't need any mobile to transmit on
uplink, but i use 7, because it is never assigend to any mobile).
regards,
andreas
From: Holger Hans Peter Freyther <holger(a)freyther.de>
libosmocore might not be in the standard include path,
add the CFLAGS to the preprocessor flags. This is fixing
the build on the Osmocom Jenkins.
---
src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 041831f..98574fa 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -18,7 +18,7 @@
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
-AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES)
+AM_CPPFLAGS = $(STD_DEFINES_AND_INCLUDES) $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGB_CFLAGS) $(LIBOSMOGSM_CFLAGS)
AM_CXXFLAGS = -Wall -ldl -pthread
noinst_LTLIBRARIES = libgprs.la
--
1.7.10.4
Hi all!
while reviewing the current PCU code in the git repository, it occurred
to me that somehow the jolly_new branch doesn't seem to be based on
master, and the only common ancestor is
9b06ff0c4c49f1927b9029d38e16670a7b7301fb from June 15.
In fact, Ivan seems to have made a number of changes concurrently with
Andreas, but not basing on each other's code. It's really a big mess,
from what I can tell.
I'm referring to the followign commit's by Ivan:
a9e6dc5084627e7c279ba08de7a7809e97ebc539
d78ee736239414021fde8010179f42b86464a238
Which are completely unrelated to the work that Andreas has been doing
at the same time (all his commit's from 2012-06-27 on, i.e.
39621c41f303e24b7324dc4c91447a449d2a654b and later.
I strongly recomend that you coordinate more and re-view each others'
code better.
And regarding the messy situatin with master vs. jolly_new: I think the
only practical solution is to drop one of the two parallel and
incompatible changes regarding the RLC/MAC and TBF establishment
changes.
Do you have any input on how to resolve this specific issue? I think
none of us can afford to waste resources on duplication of work and
creating virtually un-mergeable branches :/
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi laforge,
just curios about two lines at oml.c:
rlcc->parameter[T_DL_TBF_EXT] = *(uint16_t *)cur * 10;
rlcc->parameter[T_UL_TBF_EXT] = *(uint16_t *)cur * 10;
1. isnt it * 2 instead of * 10? i just saw a comment at openbsc for 0,
250 which says: 500.
2. did you forget ntoh(*(uint16_t *)cur)?
regards,
andreas
hi,
finally the TBF acknowledge mode works in up- and downlink. i have
tested it with attachment/detachment and routing area update. changes
are commited to jolly branch.
don't be shocked, but there great changes to previous gprs_rlcmac.cpp
code. it is split into three sources:
- gprs_rlcmac.cpp: general functions to handle TBF instances,
hand-hacked codings
- gprs_rlcmac_data.cpp: handling of uplink and downlink TBF
- gprs_rlcmac_sched.cpp: scheduler to handle ready-to-send requests.
during packet idle mode, assignment of up- or downlink TBF is performed
using IMMEDIATE ASSIGMENT on AGCH. during TBF uplink, downlink
assignment is performed using PACKET DOWNLINK ASSIGNMENT on PACCH. after
TBF downlink, further downlink assignment is performed using PACKET
DOWNLINK ASSIGNMENT. during TBF downlink, uplink assignment is performed
using PACKET UPLINK assignment. this way an attachment / RA update /
detach will complete while staying in packet transfer mode, so no
further assignment must be done on AGCH.
the acknowledged mode keeps states about transmitted and received
blocks, so unreceived or unacknowledged block are retransmitted as
defined in TS 04.60. downlink RLC/MAC data and control blocks are not
queued, but generated at ready-to-send request from layer 1.
a scheduler is used to schedule next RLC/MAC block. it uses round-robin
scheduling, if more than two flows are active in one direction. in
downlink direction, control blocks are prioized. in uplink direction,
polling of mobile is priorized. (USF is set to apply uplink ressource to
MS.) only one timeslot (first PDCH) is used to share the ressources,
currently.
there is a short description (tbf.txt) about states and the process of
current code.
in order to detect missing responses on polling MS, a
gprs_rlcmac_poll_timeout() function is called. layer 1 interface must
implement detection of missed polled uplink control blocks. there are
two ways to perform this:
- The received frame is bad (BFI).
- The GSM indicates that the block should have been already received.
currently pcu_l1_if.c is broken, because none of the detection above is
performed.
best regards,
andreas
Hi Andreas,
I've looked through your commits and looks like you're doing a very
quick progress. Your changes are overlapping with Ivan's work and I
would recommend to merge them the master as often as possible to avoid
duplicated efforts and code divergence. From this quick review I've
got impression that code needs clean up before the merge, so it would
be good if you share your plans on this.
As a general comment, I think we could do merging of your code into
master, but it would be much, much easier if you commit in smaller
"atomic" chunks. E.g. these two last commits contain more changes then
is written in the commit logs and in my opinion should be splitted
into several independent commits.
Note, that I just want to share my opinion and it's up to you and Ivan
to decide how to work together efficiently.
On Thu, Jul 5, 2012 at 6:42 AM, git repository hosting
<gitosis(a)osmocom.org> wrote:
> 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 "UNNAMED PROJECT".
>
> The branch, jolly has been updated
> via f3d060c6310bfa979225b871ba463284d3cda887 (commit)
> via 06b195e43e36c0b5100ab03e80fcc87a10db9fc5 (commit)
> from e6228b34a75efcb6b0700ac29672d62539860fbf (commit)
>
> 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/cgit/osmo-pcu/commit/?id=f3d060c6310bfa979225b871ba…
>
> commit f3d060c6310bfa979225b871ba463284d3cda887
> Author: Andreas Eversberg <jolly(a)eversberg.eu>
> Date: Thu Jul 5 07:38:49 2012 +0200
>
> Fixed pseudo length of IMMEDIATE ASSIGNMENT message.
>
> The pseudo length may not include the rest-octets, so it stays compatible
> to non-GPRS phones.
>
> At pcu_l1_if.c (OpenBTS) no pseudo length is given, so the frame is
> only 22 bytes long. I could not test if it works.
>
> http://cgit.osmocom.org/cgit/osmo-pcu/commit/?id=06b195e43e36c0b5100ab03e80…
>
> commit 06b195e43e36c0b5100ab03e80fcc87a10db9fc5
> Author: Andreas Eversberg <jolly(a)eversberg.eu>
> Date: Thu Jul 5 07:34:29 2012 +0200
>
> Use cell informations received from PCU socket interface
>
> Cell info is received from socket interface. The given parameters are
> used to replace the hardcoded values (at least for l1 socket interface).
>
> -----------------------------------------------------------------------
>
> Summary of changes:
> configure.ac | 8 ++
> src/Makefile.am | 19 ++----
> src/gprs_bssgp_pcu.cpp | 178 ++++++++++++++++++++++++++++++++++++++++++++--
> src/gprs_bssgp_pcu.h | 24 ++----
> src/gprs_debug.cpp | 2 +-
> src/gprs_rlcmac.cpp | 41 ++++++-----
> src/gprs_rlcmac.h | 25 ++++---
> src/gprs_rlcmac_data.cpp | 79 +++++++++++++-------
> src/pcu_l1_if.cpp | 37 +++++++++-
> src/pcu_main.cpp | 123 ++++++++++++++++++--------------
> src/sysmo_l1_if.cpp | 94 ++++++++++++++++++++++---
> 11 files changed, 471 insertions(+), 159 deletions(-)
>
>
> hooks/post-receive
> --
> UNNAMED PROJECT
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru