From Ivan.Kluchnikov at fairwaves.ru  Wed Sep  4 20:46:06 2013
From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov)
Date: Thu, 5 Sep 2013 00:46:06 +0400
Subject: [PATCH 01/10] bssgp: Re-indent the switch/case statement
In-Reply-To: <CA+QHiD8wqVO6Xg+CYG2_0JS4uNQ7kqBdzhqyfWHeVV-ibTeu8Q@mail.gmail.com>
References: <1377155824-7598-1-git-send-email-hfreyther@sysmocom.de>
	<20130830131344.GB17238@xiaoyu.lan>
	<CA+QHiD8wqVO6Xg+CYG2_0JS4uNQ7kqBdzhqyfWHeVV-ibTeu8Q@mail.gmail.com>
Message-ID: <CA+QHiD9WesXLhnsNbg7eE371pmOLXTMGZb5WMfpLFFhdBD4wbw@mail.gmail.com>

Hi Holger,

I tested and merged these patches to master.

2013/8/30 Ivan Kluchnikov <Ivan.Kluchnikov at fairwaves.ru>:
> Hi Holger,
>
> Sorry for delay, I plan to test and review all these patches on
> Monday, after that I will merge them.
>
> 2013/8/30 Holger Hans Peter Freyther <hfreyther at sysmocom.de>:
>> On Thu, Aug 22, 2013 at 09:16:55AM +0200, Holger Freyther wrote:
>>> From: Holger Hans Peter Freyther <holger at moiji-mobile.com>
>>
>> ping? Ivan, any feedback on these patches?
>>
>>
>> --
>> - Holger Freyther <hfreyther at 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
>>
>>
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru



-- 
Regards,
Ivan Kluchnikov.
http://fairwaves.ru



From vrolbin at gmail.com  Tue Sep 24 10:26:17 2013
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Tue, 24 Sep 2013 13:26:17 +0300
Subject: alloc_algorithm_a
Message-ID: <CAPPmnBhNRxF=WhV1_pcAJTEGNzBXX1JHwbUCChud1e2xZJiT5A@mail.gmail.com>

Hi all,

It looks like usf found (allocated) is never used. I guess something
like tbf->dir.ul.usf[ts] = usf is missed.

Regards,
Vladimir Rolbin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20130924/88781a93/attachment.htm>

From hfreyther at sysmocom.de  Wed Sep 25 10:11:32 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Wed, 25 Sep 2013 12:11:32 +0200
Subject: alloc_algorithm_a
In-Reply-To: <CAPPmnBhNRxF=WhV1_pcAJTEGNzBXX1JHwbUCChud1e2xZJiT5A@mail.gmail.com>
References: <CAPPmnBhNRxF=WhV1_pcAJTEGNzBXX1JHwbUCChud1e2xZJiT5A@mail.gmail.com>
Message-ID: <20130925101132.GE4114@xiaoyu.lan>

On Tue, Sep 24, 2013 at 01:26:17PM +0300, Vladimir Rolbin wrote:
> Hi all,
> 
> It looks like usf found (allocated) is never used. I guess something
> like tbf->dir.ul.usf[ts] = usf is missed.

Hi!

can you indicate on how to re-produce the problem and how much time
you have spent in analyzing this problem? I have indicated the lack
of test cases in the past. 

I moved the "assignment" (having to pass trx, bts, pdch, ts just
indicates the lack of structure in this code...) into a new method.
It kills code duplication and could fix the issue. I have only compile
tested it. Could you give it a try?

holger



diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp
index 1d1a8c6..695bf47 100644
--- a/src/gprs_rlcmac.cpp
+++ b/src/gprs_rlcmac.cpp
@@ -402,6 +402,17 @@ next_diagram:
 	return tbf;
 }
 
+static void assign_uplink_tbf_usf(struct gprs_rlcmac_bts *bts,
+				struct gprs_rlcmac_pdch *pdch,
+				int ts,
+				struct gprs_rlcmac_tbf *tbf, int8_t usf)
+{
+	bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
+	pdch->ul_tbf[tbf->tfi] = tbf;
+	tbf->pdch[ts] = pdch;
+	tbf->dir.ul.usf[ts] = usf;
+}
+
 /* Slot Allocation: Algorithm A
  *
  * Assign single slot for uplink and downlink
@@ -433,17 +444,14 @@ int alloc_algorithm_a(struct gprs_rlcmac_bts *bts,
 	if (tbf->direction == GPRS_RLCMAC_UL_TBF) {
 		/* if USF available */
 		usf = find_free_usf(pdch, ts);
-		if (usf >= 0) {
-			LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
-				"TS=%d USF=%d\n", ts, usf);
-			bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
-			pdch->ul_tbf[tbf->tfi] = tbf;
-			tbf->pdch[ts] = pdch;
-		} else {
+		if (usf < 0) {
 			LOGP(DRLCMAC, LOGL_NOTICE, "- Failed "
 				"allocating TS=%d, no USF available\n", ts);
 			return -EBUSY;
 		}
+		LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
+			"TS=%d USF=%d\n", ts, usf);
+		assign_uplink_tbf_usf(bts, pdch, ts, tbf, usf);
 	} else {
 		LOGP(DRLCMAC, LOGL_DEBUG, "- Assign downlink TS=%d\n", ts);
 		bts->trx[tbf->trx].dl_tbf[tbf->tfi] = tbf;
@@ -859,10 +867,7 @@ int alloc_algorithm_b(struct gprs_rlcmac_bts *bts,
 				LOGP(DRLCMAC, LOGL_DEBUG, "- Assigning UL TS "
 					"%d\n", ts);
 				pdch = &bts->trx[tbf->trx].pdch[ts];
-				bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
-				pdch->ul_tbf[tbf->tfi] = tbf;
-				tbf->pdch[ts] = pdch;
-				tbf->dir.ul.usf[ts] = usf[ts];
+				assign_uplink_tbf_usf(bts, pdch, ts, tbf, usf[ts]);
 				slotcount++;
 				if (slotcount == 1)
 					tbf->first_ts = ts;

-- 
- Holger Freyther <hfreyther at 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 vrolbin at gmail.com  Wed Sep 25 11:39:55 2013
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Wed, 25 Sep 2013 13:39:55 +0200
Subject: alloc_algorithm_a
In-Reply-To: <20130925101132.GE4114@xiaoyu.lan>
References: <CAPPmnBhNRxF=WhV1_pcAJTEGNzBXX1JHwbUCChud1e2xZJiT5A@mail.gmail.com>
	<20130925101132.GE4114@xiaoyu.lan>
Message-ID: <CAPPmnBiqcS=+zS9j9E+dDRWhkzaQK0hysmRvYfetpueQVQQS7A@mail.gmail.com>

I paid attention that when mode "a" used ( 1 ts configuration)  0  is the
only usf value allocated in spite of two MSs are involved in the test. I
understand that it may be OK if they haven't opened UL TBFs at the same
time, but analyzing the source code I didn't find that the local variable
usf after getting value delivers it further to   tbf->dir.ul.usf[ts] or I'm
missing something. I'll try the patch later (in several days).

Regards,
Vladimir Rolbin




On Wed, Sep 25, 2013 at 1:11 PM, Holger Hans Peter Freyther <
hfreyther at sysmocom.de> wrote:

> On Tue, Sep 24, 2013 at 01:26:17PM +0300, Vladimir Rolbin wrote:
> > Hi all,
> >
> > It looks like usf found (allocated) is never used. I guess something
> > like tbf->dir.ul.usf[ts] = usf is missed.
>
> Hi!
>
> can you indicate on how to re-produce the problem and how much time
> you have spent in analyzing this problem? I have indicated the lack
> of test cases in the past.
>
> I moved the "assignment" (having to pass trx, bts, pdch, ts just
> indicates the lack of structure in this code...) into a new method.
> It kills code duplication and could fix the issue. I have only compile
> tested it. Could you give it a try?
>
> holger
>
>
>
> diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp
> index 1d1a8c6..695bf47 100644
> --- a/src/gprs_rlcmac.cpp
> +++ b/src/gprs_rlcmac.cpp
> @@ -402,6 +402,17 @@ next_diagram:
>         return tbf;
>  }
>
> +static void assign_uplink_tbf_usf(struct gprs_rlcmac_bts *bts,
> +                               struct gprs_rlcmac_pdch *pdch,
> +                               int ts,
> +                               struct gprs_rlcmac_tbf *tbf, int8_t usf)
> +{
> +       bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> +       pdch->ul_tbf[tbf->tfi] = tbf;
> +       tbf->pdch[ts] = pdch;
> +       tbf->dir.ul.usf[ts] = usf;
> +}
> +
>  /* Slot Allocation: Algorithm A
>   *
>   * Assign single slot for uplink and downlink
> @@ -433,17 +444,14 @@ int alloc_algorithm_a(struct gprs_rlcmac_bts *bts,
>         if (tbf->direction == GPRS_RLCMAC_UL_TBF) {
>                 /* if USF available */
>                 usf = find_free_usf(pdch, ts);
> -               if (usf >= 0) {
> -                       LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
> -                               "TS=%d USF=%d\n", ts, usf);
> -                       bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> -                       pdch->ul_tbf[tbf->tfi] = tbf;
> -                       tbf->pdch[ts] = pdch;
> -               } else {
> +               if (usf < 0) {
>                         LOGP(DRLCMAC, LOGL_NOTICE, "- Failed "
>                                 "allocating TS=%d, no USF available\n",
> ts);
>                         return -EBUSY;
>                 }
> +               LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
> +                       "TS=%d USF=%d\n", ts, usf);
> +               assign_uplink_tbf_usf(bts, pdch, ts, tbf, usf);
>         } else {
>                 LOGP(DRLCMAC, LOGL_DEBUG, "- Assign downlink TS=%d\n", ts);
>                 bts->trx[tbf->trx].dl_tbf[tbf->tfi] = tbf;
> @@ -859,10 +867,7 @@ int alloc_algorithm_b(struct gprs_rlcmac_bts *bts,
>                                 LOGP(DRLCMAC, LOGL_DEBUG, "- Assigning UL
> TS "
>                                         "%d\n", ts);
>                                 pdch = &bts->trx[tbf->trx].pdch[ts];
> -                               bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> -                               pdch->ul_tbf[tbf->tfi] = tbf;
> -                               tbf->pdch[ts] = pdch;
> -                               tbf->dir.ul.usf[ts] = usf[ts];
> +                               assign_uplink_tbf_usf(bts, pdch, ts, tbf,
> usf[ts]);
>                                 slotcount++;
>                                 if (slotcount == 1)
>                                         tbf->first_ts = ts;
>
> --
> - Holger Freyther <hfreyther at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20130925/982cb3bf/attachment.htm>

From hfreyther at sysmocom.de  Sun Sep 29 05:25:19 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Sun, 29 Sep 2013 07:25:19 +0200
Subject: [PATCH 1/3] tfi: The tfi_alloc doesn't allocate anything, rename
	the function
In-Reply-To: <1377428496-21721-1-git-send-email-hfreyther@sysmocom.de>
References: <1377428496-21721-1-git-send-email-hfreyther@sysmocom.de>
Message-ID: <20130929052519.GA25274@xiaoyu.lan>

On Sun, Aug 25, 2013 at 01:01:34PM +0200, Holger Hans Peter Freyther wrote:
> From: Holger Hans Peter Freyther <holger at moiji-mobile.com>

Hi,


> Call things by what they do and this function doesn't allocate
> anything but it is searching for the first unallocated tbf index.

it appears that this patchset has not ben reviewed/merged. Do you
have time to review/test/merge these cleanups?

holger


-- 
- Holger Freyther <hfreyther at 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 hfreyther at sysmocom.de  Sun Sep 29 07:31:42 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Sun, 29 Sep 2013 09:31:42 +0200
Subject: Question regarding TS allocation algorithm(s)
Message-ID: <20130929073142.GV25860@xiaoyu.lan>

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 at 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 andreas at eversberg.eu  Sun Sep 29 08:15:50 2013
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Sun, 29 Sep 2013 10:15:50 +0200
Subject: Question regarding TS allocation algorithm(s)
In-Reply-To: <20130929073142.GV25860@xiaoyu.lan>
References: <20130929073142.GV25860@xiaoyu.lan>
Message-ID: <5247E1B6.2040302@eversberg.eu>

Holger Hans Peter Freyther wrote:
> 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?
>   
dear holger,

it is true tat algorithm A only assigns the first PDCH time slot. i
don't see any problems changing that by spreading TBF usage over all
available PDCHs.

in case of algorithm B it is a bit different. we want to assign a
certain PDCH time slot for uplink, so we can be sure that the phone is
able to receive all supported downlink PDCH slots, if an additional
downlink TBF is assigned. for a class 12 mobile (as used today), we can
assign up to 4 PDCHs for downlink. in this case we must assign the third
PDCH for uplink, otherwise semi-duplex operation is not possible with
all 4 time slots. but again, it would be possible to spread uplink and
downlink assignment, if we have more than 4 PDCHs. this makes the
algorithm more complex.

regards,

andreas




From hfreyther at sysmocom.de  Sun Sep 29 09:05:05 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Sun, 29 Sep 2013 11:05:05 +0200
Subject: Question regarding TS allocation algorithm(s)
In-Reply-To: <5247E1B6.2040302@eversberg.eu>
References: <20130929073142.GV25860@xiaoyu.lan> <5247E1B6.2040302@eversberg.eu>
Message-ID: <20130929090505.GA25501@xiaoyu.lan>

On Sun, Sep 29, 2013 at 10:15:50AM +0200, Andreas Eversberg wrote:

> it is true tat algorithm A only assigns the first PDCH time slot. i
> don't see any problems changing that by spreading TBF usage over all
> available PDCHs.

okay. I am currently cleaning up the pcu (including the allocations
algorithms), refactor and fix the subtle bugs that are due code
duplication (e.g. like the one reported by Vladimir Rolbin). This
also means that I will be busy and stall your osmo-bts changes
until I am done with the clean-up here.

> in case of algorithm B it is a bit different. we want to assign a
> certain PDCH time slot for uplink, so we can be sure that the phone is
> able to receive all supported downlink PDCH slots, if an additional
> downlink TBF is assigned. for a class 12 mobile (as used today), we can
> assign up to 4 PDCHs for downlink. in this case we must assign the third
> PDCH for uplink, otherwise semi-duplex operation is not possible with
> all 4 time slots. but again, it would be possible to spread uplink and
> downlink assignment, if we have more than 4 PDCHs. this makes the
> algorithm more complex.

Thanks for the explanation. I think we easily end in a situation where
we can not allocate bigger windows (or windows at all) because we always
start with the first enabled PDCH.


holger


-- 
- Holger Freyther <hfreyther at 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 vrolbin at gmail.com  Mon Sep 30 14:43:00 2013
From: vrolbin at gmail.com (Vladimir Rolbin)
Date: Mon, 30 Sep 2013 17:43:00 +0300
Subject: alloc_algorithm_a
In-Reply-To: <20130925101132.GE4114@xiaoyu.lan>
References: <CAPPmnBhNRxF=WhV1_pcAJTEGNzBXX1JHwbUCChud1e2xZJiT5A@mail.gmail.com>
	<20130925101132.GE4114@xiaoyu.lan>
Message-ID: <CAPPmnBjx-x0EZHYY7aCeAEA5HwBEYHKD9FOmvFr-8SOn8gLqRQ@mail.gmail.com>

Hi,

I've added a print after the call to the uplink assignment function:

        if (usf < 0) {
LOGP(DRLCMAC, LOGL_NOTICE, "- Failed "
"allocating TS=%d, no USF available\n", ts);
return -EBUSY;
}
        LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
                       "TS=%d USF=%d\n", ts, usf);
        assign_uplink_tbf_usf(bts, pdch, ts, tbf, usf);
        LOGP(DRLCMAC, LOGL_NOTICE, "USF allocated %d ts %d\n",
tbf->dir.ul.usf[ts], ts);


Two MSs are getting different USFs now:


<0001> pcu_l1_if.cpp:290 RACH request received: sapi=1 qta=1, ra=123,
fn=1109521
<0002> gprs_rlcmac.cpp:454 USF allocated 0 ts 7
<0002> gprs_rlcmac_data.cpp:1906 Got IMM.ASS confirm, but rest octets do
not start with bit sequence 'HH01' (Packet Downlink Assignment)
<0001> pcu_l1_if.cpp:290 RACH request received: sapi=1 qta=1, ra=121,
fn=1109533
<0002> gprs_rlcmac.cpp:454 USF allocated 1 ts 7
<0002> gprs_rlcmac_data.cpp:1906 Got IMM.ASS confirm, but rest octets do
not start with bit sequence 'HH01' (Packet Downlink Assignment)
<0008> gprs_rlcmac.cpp:1799 LLC [PCU -> SGSN] TFI: 0 TLLI: 0xc0a3df97 len=79
<0008> gprs_bssgp_pcu.cpp:155 LLC [SGSN -> PCU] = TLLI: 0xc0a3df97 IMSI:
334020481442858 len: 191
<0007> gprs_rlcmac_meas.cpp:102 UL RSSI of TLLI=0xc0a3df97: 0 dBm
<0008> gprs_rlcmac.cpp:1799 LLC [PCU -> SGSN] TFI: 1 TLLI: 0xf844d86d len=8
<0007> gprs_rlcmac_meas.cpp:102 UL RSSI of TLLI=0xf844d86d: 0 dBm
<0002> gprs_rlcmac_data.cpp:1549 Polling sheduled in this TS 7, FN 1109736

And it works. Both of them succeeded to open the internet page..
Without deep investigation alloc_b works as well (after patch applying).

Regards,
Vladimir.





On Wed, Sep 25, 2013 at 1:11 PM, Holger Hans Peter Freyther <
hfreyther at sysmocom.de> wrote:

> On Tue, Sep 24, 2013 at 01:26:17PM +0300, Vladimir Rolbin wrote:
> > Hi all,
> >
> > It looks like usf found (allocated) is never used. I guess something
> > like tbf->dir.ul.usf[ts] = usf is missed.
>
> Hi!
>
> can you indicate on how to re-produce the problem and how much time
> you have spent in analyzing this problem? I have indicated the lack
> of test cases in the past.
>
> I moved the "assignment" (having to pass trx, bts, pdch, ts just
> indicates the lack of structure in this code...) into a new method.
> It kills code duplication and could fix the issue. I have only compile
> tested it. Could you give it a try?
>
> holger
>
>
>
> diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp
> index 1d1a8c6..695bf47 100644
> --- a/src/gprs_rlcmac.cpp
> +++ b/src/gprs_rlcmac.cpp
> @@ -402,6 +402,17 @@ next_diagram:
>         return tbf;
>  }
>
> +static void assign_uplink_tbf_usf(struct gprs_rlcmac_bts *bts,
> +                               struct gprs_rlcmac_pdch *pdch,
> +                               int ts,
> +                               struct gprs_rlcmac_tbf *tbf, int8_t usf)
> +{
> +       bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> +       pdch->ul_tbf[tbf->tfi] = tbf;
> +       tbf->pdch[ts] = pdch;
> +       tbf->dir.ul.usf[ts] = usf;
> +}
> +
>  /* Slot Allocation: Algorithm A
>   *
>   * Assign single slot for uplink and downlink
> @@ -433,17 +444,14 @@ int alloc_algorithm_a(struct gprs_rlcmac_bts *bts,
>         if (tbf->direction == GPRS_RLCMAC_UL_TBF) {
>                 /* if USF available */
>                 usf = find_free_usf(pdch, ts);
> -               if (usf >= 0) {
> -                       LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
> -                               "TS=%d USF=%d\n", ts, usf);
> -                       bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> -                       pdch->ul_tbf[tbf->tfi] = tbf;
> -                       tbf->pdch[ts] = pdch;
> -               } else {
> +               if (usf < 0) {
>                         LOGP(DRLCMAC, LOGL_NOTICE, "- Failed "
>                                 "allocating TS=%d, no USF available\n",
> ts);
>                         return -EBUSY;
>                 }
> +               LOGP(DRLCMAC, LOGL_DEBUG, "- Assign uplink "
> +                       "TS=%d USF=%d\n", ts, usf);
> +               assign_uplink_tbf_usf(bts, pdch, ts, tbf, usf);
>         } else {
>                 LOGP(DRLCMAC, LOGL_DEBUG, "- Assign downlink TS=%d\n", ts);
>                 bts->trx[tbf->trx].dl_tbf[tbf->tfi] = tbf;
> @@ -859,10 +867,7 @@ int alloc_algorithm_b(struct gprs_rlcmac_bts *bts,
>                                 LOGP(DRLCMAC, LOGL_DEBUG, "- Assigning UL
> TS "
>                                         "%d\n", ts);
>                                 pdch = &bts->trx[tbf->trx].pdch[ts];
> -                               bts->trx[tbf->trx].ul_tbf[tbf->tfi] = tbf;
> -                               pdch->ul_tbf[tbf->tfi] = tbf;
> -                               tbf->pdch[ts] = pdch;
> -                               tbf->dir.ul.usf[ts] = usf[ts];
> +                               assign_uplink_tbf_usf(bts, pdch, ts, tbf,
> usf[ts]);
>                                 slotcount++;
>                                 if (slotcount == 1)
>                                         tbf->first_ts = ts;
>
> --
> - Holger Freyther <hfreyther at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20130930/cde35a84/attachment.htm>

From hfreyther at sysmocom.de  Mon Sep 30 16:01:05 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Mon, 30 Sep 2013 18:01:05 +0200
Subject: Question regarding TS allocation algorithm(s)
In-Reply-To: <20130929090505.GA25501@xiaoyu.lan>
References: <20130929073142.GV25860@xiaoyu.lan> <5247E1B6.2040302@eversberg.eu>
	<20130929090505.GA25501@xiaoyu.lan>
Message-ID: <20130930160105.GA15806@xiaoyu.lan>

On Sun, Sep 29, 2013 at 11:05:05AM +0200, Holger Hans Peter Freyther wrote:
> On Sun, Sep 29, 2013 at 10:15:50AM +0200, Andreas Eversberg wrote:
> 
> > it is true tat algorithm A only assigns the first PDCH time slot. i
> > don't see any problems changing that by spreading TBF usage over all
> > available PDCHs.
> 
> okay. I am currently cleaning up the pcu (including the allocations
> algorithms), refactor and fix the subtle bugs that are due code
> duplication (e.g. like the one reported by Vladimir Rolbin). This
> also means that I will be busy and stall your osmo-bts changes
> until I am done with the clean-up here.

Okay, I started to read GSM 04.60 and the code. So right now we have
"global TFIs" so in each direction we can not allocate 32 TFIs right
now.

The spec says this:
"Each TBF is assigned a Temporary Flow Identity (TFI) by the network.
The mobile station shall assume that the TFI value is unique among
concurrent TBFs in the same direction (uplink or downlink) on all PDCHs
used for the TBF. The same TFI value may be used concurrently for TBFs
on other PDCHs in the same direction and for TBFs in the opposite
direction."

So if we combine the tfi/tbf allocation we could remove the current
limitation. I have some more ideas for cleanup after reading some more
of the code. I would propose to stick with C++ at this point in time
as information hiding (e.g. making certain parts of a struct private
can help with the structure of the code.)

holger



-- 
- Holger Freyther <hfreyther at 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