Review at https://gerrit.osmocom.org/180
dyn PDCH: allow allocating TCH/F on TCH/F_PDCH slots
See comment added in the code.
Original patch by jolly, but split in two, added comment and flipped the if()
logic for readability by nhofmeyr.
Change-Id: Iddd575873a2fe819fc182a6b3d4186caea1997e5
---
M openbsc/src/libbsc/chan_alloc.c
1 file changed, 10 insertions(+), 8 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/80/180/1
diff --git a/openbsc/src/libbsc/chan_alloc.c b/openbsc/src/libbsc/chan_alloc.c
index 8600846..cd25bd9 100644
--- a/openbsc/src/libbsc/chan_alloc.c
+++ b/openbsc/src/libbsc/chan_alloc.c
@@ -96,14 +96,16 @@
ts = &trx->ts[j];
if (!ts_is_usable(ts))
continue;
- /* ip.access dynamic TCH/F + PDCH combination */
- if (ts->pchan == GSM_PCHAN_TCH_F_PDCH &&
- pchan == GSM_PCHAN_TCH_F) {
- /* we can only consider such a dynamic channel
- * if the PDCH is currently inactive */
- if (ts->flags & TS_F_PDCH_MODE)
- continue;
- } else if (ts->pchan != pchan)
+ /*
+ * pchan must match; but when looking for TCH/F, allow a match
+ * with TCH/F_PDCH, to return dynamic TCH/F_PDCH slots to the
+ * channel allocator. Thus the channel allocator can pick a
+ * TCH/F_PDCH time slot and disable its PDCH later on (no need
+ * to check whether PDCH mode is currently active here).
+ */
+ if (!(ts->pchan == pchan
+ || (ts->pchan == GSM_PCHAN_TCH_F_PDCH
+ && pchan == GSM_PCHAN_TCH_F)))
continue;
/* check if all sub-slots are allocated yet */
for (ss = 0; ss < subslots_per_pchan[pchan]; ss++) {
--
To view, visit https://gerrit.osmocom.org/180
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Iddd575873a2fe819fc182a6b3d4186caea1997e5
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Review at https://gerrit.osmocom.org/176
comment tweak for bsc_handover_start()
Have a comment only in the .c file to remove dup, tweak wording.
Change-Id: If054dad877a1ca750cd72be9c9d90bcf087bf741
---
M openbsc/include/openbsc/handover.h
M openbsc/src/libbsc/handover_logic.c
2 files changed, 3 insertions(+), 6 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/76/176/1
diff --git a/openbsc/include/openbsc/handover.h b/openbsc/include/openbsc/handover.h
index bd0d8ad..3fe71a2 100644
--- a/openbsc/include/openbsc/handover.h
+++ b/openbsc/include/openbsc/handover.h
@@ -3,9 +3,6 @@
struct gsm_subscriber_connection;
-/* Hand over the specified logical channel to the specified new BTS.
- * This is the main entry point for the actual handover algorithm,
- * after it has decided it wants to initiate HO to a specific BTS */
int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts);
/* clear any operation for this connection */
diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c
index 2b8c386..641cee4 100644
--- a/openbsc/src/libbsc/handover_logic.c
+++ b/openbsc/src/libbsc/handover_logic.c
@@ -85,9 +85,9 @@
return NULL;
}
-/* Hand over the specified logical channel to the specified new BTS.
- * This is the main entry point for the actual handover algorithm,
- * after it has decided it wants to initiate HO to a specific BTS */
+/* Hand over the specified logical channel to the specified new BTS. This is
+ * the main entry point for the actual handover algorithm, after the decision
+ * whether to initiate HO to a specific BTS. */
int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts)
{
struct gsm_lchan *new_lchan;
--
To view, visit https://gerrit.osmocom.org/176
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If054dad877a1ca750cd72be9c9d90bcf087bf741
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Hi all,
I have a Osmocom setup running with a Ettus B200
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
The latest "good" revision I am aware of is commit
d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
I tried again today with commit 2fcfc29020c81891d7888ddc7ddbcd866bcd406d
(2016/05/24) and not a single handset could establish data communication
Reading osmo-pcu logs show that T6169 timeouts during TBF assignment :
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:479 MS requests UL TBF on RACH, so we provide one:
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here **********
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:407 Searching for first unallocated TFI: TRX=0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:417 Found TFI=0.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)".CCCCCCC"(TS=7)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"...U...."(TS=7), single
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 3 for UL
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"...C...."(TS=7)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 3
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 3, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 3
> Fri May 27 15:51:38 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 08, dl_slots = 00
> Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW
> Fri May 27 15:51:38 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169.
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:523 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:527 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x7b, Fn=1607859 (28,33,19)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:529 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH)
> Fri May 27 15:51:38 2016 DRLCMAC <0002> bts.cpp:542 - TRX=0 (128) TS=3 TA=0 TSC=3 TFI=0 USF=0
> Fri May 27 15:51:38 2016 DRLCMAC <0002> ./tbf.h:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired.
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout
> Fri May 27 15:51:43 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free
Every element of the stack is running with today's revision on master
(cheers for making it happen without specific branches by the way).
With the same setup with
osmo-pcu@d87e1d6ab747423d3668c74d16201a5d967accf0, I get solid data
rates around 40 Kbits/s.
I haven't seen anybody on the mailing list experiencing the same
behavior, making me believe that it could be specific to osmo-bts-trx /
osmo-trx users.
Can somebody confirm or reproduce this attitude ?
I will try to provide more logs and a pcap capture as soon as I get
hands back on the hardware.
Hi.
Right now in osmobts when sending/receiving frames with osmo_rtp_* it's
assumed that no frame is lost and timestamp is always advanced in 160ms
steps. In practice (especially when DTX is in place) frames do get lost
so we have to adjust the step to compensate.
I've tried to do it as follows:
- store frame number of last used frame on receiving/sending
- check how far current frame number from old one
- convert frame number delta to ms: each frame is 4.615 ms long
- if delta in ms is bigger than default 160 than use it
However the result sound not much better than using hardcoded value
which suggest that I might be doing FN -> ms conversion (or smth else)
wrong. Any ideas/advices?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
On Wed, Jun 01, 2016 at 09:02:47PM +0200, Holger Freyther wrote:
> > On 01 Jun 2016, at 14:21, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote:
> >
> > It would also be nice if Gerrit didn't complain about merge conflicts that are
> > in fact no merge conflicts -- I'm stumped on that topic. Any help would be
> > appreciated.
>
> https://code.google.com/p/gerrit/issues/detail?id=2734
Thanks! #5 is extremely helpful in understanding Gerrit: I did absolutely not
expect the term "merge conflict" to actually mean "path conflict".
https://code.google.com/p/gerrit/issues/detail?id=2734#c5
What the post says to be "Automatically resolve conflicts" is probably "Allow
content merges" in our Gerrit version. It's now enabled in our projects (thanks
Holger).
Next I'd like to retry the "Rebase if necessary". Currently openbsc was on
"Merge if necessary", which, it seems, creates merges that make the history
more complex than rebases would.
I've put openbsc to "Rebase if necessary" now and posted the next couple iups
commits to for/master.
This time I don't see "Merge conflicts", probably thanks to "Allow content
merges"; excellent.
I have yet another problem: it seems I can't re-submit a branch; during push, I
get an error saying:
! [remote rejected] HEAD -> refs/for/master (no new changes)
I've resolved "no new changes" before by manually removing the Change-Id from
each commit message (kind of unsatisfactory solution). This means I can't
submit fixes to the branch commits. I would like to add the NULL check
described in the comment here:
https://gerrit.osmocom.org/#/c/171/1/openbsc/src/gprs/gprs_gmm.c
but it seems I would have to abandon the entire set and submit it again, and
would also have to amend every commit message to generate a new Change-Id in
it. (This particular change could well be added in a later commit, but it
makes me wonder how we work with requests to tweak such a commit in general.)
https://groups.google.com/forum/?_escaped_fragment_=topic/repo-discuss/NeuQ…
^ This looks like gerrit and branches just don't mix too well.
https://groups.google.com/forum/?_escaped_fragment_=topic/repo-discuss/tmiy…
^ In here there's also the suggestion to push a merge-commit to for/master
instead, so I might try it next time...
BTW I think I was wrong about the shuffling of commits in the listing. It
appears the newest branch commit is always on the bottom. (Except in "Related
changes", where it is always on top.)
I guess we should have a "submitting branches in gerrit" wiki page once we've
settled for our favourite strategy.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Review at https://gerrit.osmocom.org/168
gprs_gmm.c: Don't try to de-reference NULL mmctx
There was a comment in the code that certain GMM messages require a
valid mmctx pointer. However, nothing actually checked if that pointer
was in fact non-NULL. We plainly crashed if a MS would send us the
wrong message in the wrong state.
Original patch by Harald Welte, but it broke message validity checking,
resulting in sgsn_test failure. This re-implements the NULL check in a
different way, as explained by in-code comment.
Change-Id: I34b47b9e63691c9bc9904573000c74877217f679
---
M openbsc/src/gprs/gprs_gmm.c
1 file changed, 32 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/68/168/1
diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c
index 1e10701..e788e3d 100644
--- a/openbsc/src/gprs/gprs_gmm.c
+++ b/openbsc/src/gprs/gprs_gmm.c
@@ -1339,6 +1339,15 @@
return rc;
}
+ /*
+ * For a few messages, mmctx may be NULL. For most, we want to ensure a
+ * non-NULL mmctx. At the same time, we want to keep the message
+ * validity check intact, so that all message types appear in the
+ * switch statement and the default case thus means "unknown message".
+ * If we split the switch in two parts to check non-NULL halfway, the
+ * unknown-message check breaks, or we'd need to duplicate the switch
+ * cases in both parts. Just keep one large switch and add some gotos.
+ */
switch (gh->msg_type) {
case GSM48_MT_GMM_RA_UPD_REQ:
rc = gsm48_rx_gmm_ra_upd_req(mmctx, msg, llme);
@@ -1348,20 +1357,30 @@
break;
/* For all the following types mmctx can not be NULL */
case GSM48_MT_GMM_ID_RESP:
+ if (!mmctx)
+ goto null_mmctx;
rc = gsm48_rx_gmm_id_resp(mmctx, msg);
break;
case GSM48_MT_GMM_STATUS:
+ if (!mmctx)
+ goto null_mmctx;
rc = gsm48_rx_gmm_status(mmctx, msg);
break;
case GSM48_MT_GMM_DETACH_REQ:
+ if (!mmctx)
+ goto null_mmctx;
rc = gsm48_rx_gmm_det_req(mmctx, msg);
break;
case GSM48_MT_GMM_DETACH_ACK:
+ if (!mmctx)
+ goto null_mmctx;
LOGMMCTXP(LOGL_INFO, mmctx, "-> DETACH ACK\n");
mm_ctx_cleanup_free(mmctx, "GPRS DETACH ACK");
rc = 0;
break;
case GSM48_MT_GMM_ATTACH_COMPL:
+ if (!mmctx)
+ goto null_mmctx;
/* only in case SGSN offered new P-TMSI */
LOGMMCTXP(LOGL_INFO, mmctx, "-> ATTACH COMPLETE\n");
mmctx_timer_stop(mmctx, 3350);
@@ -1380,6 +1399,8 @@
osmo_signal_dispatch(SS_SGSN, S_SGSN_ATTACH, &sig_data);
break;
case GSM48_MT_GMM_RA_UPD_COMPL:
+ if (!mmctx)
+ goto null_mmctx;
/* only in case SGSN offered new P-TMSI */
LOGMMCTXP(LOGL_INFO, mmctx, "-> ROUTING AREA UPDATE COMPLETE\n");
mmctx_timer_stop(mmctx, 3350);
@@ -1398,6 +1419,8 @@
osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data);
break;
case GSM48_MT_GMM_PTMSI_REALL_COMPL:
+ if (!mmctx)
+ goto null_mmctx;
LOGMMCTXP(LOGL_INFO, mmctx, "-> PTMSI REALLLICATION COMPLETE\n");
mmctx_timer_stop(mmctx, 3350);
mmctx->t3350_mode = GMM_T3350_MODE_NONE;
@@ -1409,6 +1432,8 @@
rc = 0;
break;
case GSM48_MT_GMM_AUTH_CIPH_RESP:
+ if (!mmctx)
+ goto null_mmctx;
rc = gsm48_rx_gmm_auth_ciph_resp(mmctx, msg);
break;
default:
@@ -1419,6 +1444,13 @@
}
return rc;
+
+null_mmctx:
+ LOGP(DMM, LOGL_ERROR,
+ "Received GSM 04.08 message type 0x%02x,"
+ " but no MM context available\n",
+ gh->msg_type);
+ return -EINVAL;
}
static void mmctx_timer_cb(void *_mm)
--
To view, visit https://gerrit.osmocom.org/168
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I34b47b9e63691c9bc9904573000c74877217f679
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
So after some blood boiling to my head (sorry about that), I hit rebase, waited
for jenkins and then the change could be merged. Next I have to hit rebase on
all following commits submitted from the same branch.
It would be nice if Gerrit could have the series of branch commits in-a-row and
rebase them together in one flush, especially since they depend on each other.
Also I find it hard to see the intended sequence of branch commits. The sorting
of patches changes by updating the patch submission, so the branch commits in
the Gerrit UI are potentially re-ordered regularly.
Would it make sense to locally merge the branch to master and submit the
resulting merge-commit for review instead? Then Gerrit would treat it as a
single patch, yet the merge commit could contain any number of "sub" commits?
It would also be nice if Gerrit didn't complain about merge conflicts that are
in fact no merge conflicts -- I'm stumped on that topic. Any help would be
appreciated.
Sorry again and thanks for any hints!
~Neels
On Tue, May 31, 2016 at 11:25:38AM +0000, lynxis lazus wrote:
> Review at https://gerrit.osmocom.org/145
I'm confused. Gerrit says this change could not be merged. Then how on earth
can Jenkins add a +1 for a successful build to it??
Something about these gerrit merge conflicts is completely wrong. I'd
appreciate if we could clarify this. Any ideas on how to find out?
~Neels