hi,
i try to unterstand downlink assignment. there are two ways to perform it:
- on AGCH/PAGCH when mobile is in packet idle mode
- on PACCH when mobile is in packet transfer mode (currently ongoing
uplink TBF)
(for establishment of uplink TBF in packet idle mode, the mobile repeats
channel requests after one second timeout.)
i don't see any procedure how the networks repeats a downlink
assignment, if there is no response from the mobile (if downlink
assignment got lost, hence it was not received by mobile). the only
logical procedure i can see is that the messages from SGSN will get
dropped during release of downlink TBF. (the release happens, because
there is no response from mobile to polling of downlink acknowledgements.)
regards,
andreas
Hi Andreas,
JFYI: Not sure whether this is intentional, but select_pdch()
implementation is missing in this commit.
On Mon, Jun 25, 2012 at 9:29 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 7d7cf54f39b9136749d47336576688ce150be49d (commit)
> from 055340801b3ab7e04854c6ec5d367765037e38fd (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=7d7cf54f39b9136749d4733657…
>
> commit 7d7cf54f39b9136749d47336576688ce150be49d
> Author: Andreas Eversberg <jolly(a)eversberg.eu>
> Date: Mon Jun 25 09:26:15 2012 +0200
>
> Packet Downlink Assigment now uses ARFCN/TN of current BTS layout
>
> Now the MS receives dowlink LLC frames.
>
> -----------------------------------------------------------------------
>
> Summary of changes:
> src/gprs_bssgp_pcu.cpp | 9 ++++++++-
> src/gprs_rlcmac.cpp | 22 +++++++++-------------
> src/gprs_rlcmac.h | 2 ++
> 3 files changed, 19 insertions(+), 14 deletions(-)
>
>
> hooks/post-receive
> --
> UNNAMED PROJECT
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi, Andreas!
I think it makes sense, especially for the implementation of the USF
management.
Moreover we should find the easy and functional way to set right USF at the
right time.
All patches are welcome! :)
2012/6/18 Andreas Eversberg <andreas(a)eversberg.eu>
> hi,
>
> while reading l1_if.c, i found it usefull to move the ready-to-send-req
> handling to gprs_rlcmac.cpp, because composing of data block (or idle
> blocks) should be done when they are about to be sent and not stored in a
> queue for the following reasons:
>
> - USF can be controlled close to the time when the block is transmitted.
> - acknowledged RLC would require that, it can react directly on
> acknowledgements and select the right packet.
> - LLC frames can be flushed by SGSN, so transmission stops immediately.
> - QoS / control blocks can be scheduled more adequate.
>
> for now, i think it is ok to keep the send-queue, but move it to
> gprs_rlcmac.cpp. later the queue should be obsolete, if segmentation is
> performed "just in time", as well as uplink control. a queue should be used
> for LLC frames _before_ segmentation.
>
> any complains/suggestions? if not, i would provide a patch for that.
>
> regards,
>
> andreas
>
>
>
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
hi,
while reading l1_if.c, i found it usefull to move the ready-to-send-req
handling to gprs_rlcmac.cpp, because composing of data block (or idle
blocks) should be done when they are about to be sent and not stored in
a queue for the following reasons:
- USF can be controlled close to the time when the block is transmitted.
- acknowledged RLC would require that, it can react directly on
acknowledgements and select the right packet.
- LLC frames can be flushed by SGSN, so transmission stops immediately.
- QoS / control blocks can be scheduled more adequate.
for now, i think it is ok to keep the send-queue, but move it to
gprs_rlcmac.cpp. later the queue should be obsolete, if segmentation is
performed "just in time", as well as uplink control. a queue should be
used for LLC frames _before_ segmentation.
any complains/suggestions? if not, i would provide a patch for that.
regards,
andreas
Ivan,
This is a dab approach to naming constants - prone to collisions with
some other names in future. Generic names like "RELEASE" are
particularly bad. You have to add some prefix to those names. This
should make reading the code easier as well.
enum gprs_rlcmac_tbf_state {
- GPRS_RLCMAC_WAIT_DATA_SEQ_START,
- GPRS_RLCMAC_WAIT_NEXT_DATA_BLOCK,
- GPRS_RLCMAC_WAIT_NEXT_DATA_SEQ
+ WAIT_ESTABLISH,
+ CCCH_ESTABLISH,
+ PACCH_ESTABLISH,
+ FINISH_ESTABLISH,
+ WAIT_DATA_TRANSFER,
+ DATA_TRANSFER,
+ FINISH_DATA_TRANSFER,
+ RELEASE
};
On Sun, Jun 17, 2012 at 8:31 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, master has been updated
> via a9e6dc5084627e7c279ba08de7a7809e97ebc539 (commit)
> from 9b06ff0c4c49f1927b9029d38e16670a7b7301fb (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=a9e6dc5084627e7c279ba08de7…
>
> commit a9e6dc5084627e7c279ba08de7a7809e97ebc539
> Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com>
> Date: Sun Jun 17 08:30:06 2012 +0400
>
> Improvement of TBF management.
> Added functions for TBF allocation, establishment, data transfer and release management.
> Modified TBF structure, added list for several LLC PDUs in one TBF.
> Added function gprs_rlcmac_tx_llc_pdus() providing transmission of several LLC PDUs in one TBF to MS.
>
> -----------------------------------------------------------------------
>
> Summary of changes:
> src/gprs_bssgp_pcu.cpp | 41 ++--
> src/gprs_rlcmac.cpp | 674 ++++++++++++++++++++++++++++++++++--------------
> src/gprs_rlcmac.h | 79 +++++--
> 3 files changed, 561 insertions(+), 233 deletions(-)
>
>
> hooks/post-receive
> --
> UNNAMED PROJECT
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
On Sat, Jun 16, 2012 at 11:33:54AM +0400, Alexander Chemeris wrote:
> Hi Harald,
Hi,
>
> Could we setup a commit mailing list to know when someone commits?
>
> And is an ability to make commit reviews, like in Google Code or github?
so far the amount of external patches were always so low that reviewing
them on the mailinglist were okay. I would propose we do the same for the
PCU. In case this doesn't scale we can introduce a Gerrit.
does it make sense?
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 Alexander,
On Sat, Jun 16, 2012 at 11:33:54AM +0400, Alexander Chemeris wrote:
> Could we setup a commit mailing list to know when someone commits?
We have normally all projects' commitlog at
http://lists.osmocom.org/mailman/listinfo/osmocom-commitlog
and I have just now added osmo-pcu.git to this list
> And is an ability to make commit reviews, like in Google Code or github?
I use neither of them, and thus don't really know what you are referring
to.
--
- 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 Alexander, Ivan and everyone else,
as per our previous private discussions, I've now imported the PCU code
to the repository, which you can see at
http://cgit.osmocom.org/cgit/osmo-pcu/
The history of the old repository was imported using git filter-branch.
I've also added an auto-foo skeleton and cleaned up some bits.
As libosmo-gb is still not properly separated from openbsc.git, the
required tree layout is something like:
ancestor/openbsc
ancestor/osmo-pcu
Right now the code doesn't build yet. Some of it is remaining OpenBTS
dependencies, some of it is the fact that the code apparently never
compiled on 64bit systems:
> csn1.cpp:65:69: error: invalid initialization of reference of type 'unsigned int&' from expression of type 'size_t {aka long unsigned int}'
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)