- osmocom-net-gprs - lists.osmocom.org

Re: Multislot finished and well tested
by Andreas Eversberg 24 Jul '12

24 Jul '12

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

1 0

[PATCH] misc: Add the libosmocore CFLAGS to the CPPFLAGS
by Holger Hans Peter Freyther 23 Jul '12

23 Jul '12

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

2 1

[PATCH] misc: Fix typos in the comments
by Holger Hans Peter Freyther 23 Jul '12

23 Jul '12

From: Holger Hans Peter Freyther <holger(a)freyther.de> ressource -> resorce shure -> sure --- src/gprs_bssgp_pcu.cpp | 4 ++-- src/gprs_rlcmac.cpp | 14 +++++++------- src/gprs_rlcmac.h | 2 +- src/gprs_rlcmac_data.cpp | 10 +++++----- src/gprs_rlcmac_sched.cpp | 20 ++++++++++---------- src/tbf.txt | 2 +- 6 files changed, 26 insertions(+), 26 deletions(-) diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp index 217acdb..dc8e454 100644 --- a/src/gprs_bssgp_pcu.cpp +++ b/src/gprs_bssgp_pcu.cpp @@ -190,7 +190,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) // Create new TBF (any TRX) tfi = tfi_alloc(GPRS_RLCMAC_DL_TBF, &trx, &ts, use_trx, first_ts); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } @@ -198,7 +198,7 @@ int gprs_bssgp_pcu_rx_dl_ud(struct msgb *msg, struct tlv_parsed *tp) tbf = tbf_alloc(tbf, GPRS_RLCMAC_DL_TBF, tfi, trx, ts, ms_class, ss); if (!tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp index d1f0b54..5284260 100644 --- a/src/gprs_rlcmac.cpp +++ b/src/gprs_rlcmac.cpp @@ -80,7 +80,7 @@ llist_head *gprs_rlcmac_tbfs_lists[] = { }; void *rlcmac_tall_ctx; -/* FIXME: spread ressources over multiple TRX. Also add option to use same +/* FIXME: spread resources over multiple TRX. Also add option to use same * TRX in case of existing TBF for TLLI in the other direction. */ /* search for free TFI and return TFI, TRX and first TS */ int tfi_alloc(enum gprs_rlcmac_tbf_direction dir, uint8_t *_trx, uint8_t *_ts, @@ -264,7 +264,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, else rc = bts->alloc_algorithm(old_tbf, tbf, bts->alloc_algorithm_curst); - /* if no ressource */ + /* if no resource */ if (rc < 0) { talloc_free(tbf); return NULL; @@ -272,7 +272,7 @@ struct gprs_rlcmac_tbf *tbf_alloc(struct gprs_rlcmac_tbf *old_tbf, /* assign control ts */ tbf->control_ts = 0xff; rc = tbf_assign_control_ts(tbf); - /* if no ressource */ + /* if no resource */ if (rc < 0) { talloc_free(tbf); return NULL; @@ -767,12 +767,12 @@ void tbf_free(struct gprs_rlcmac_tbf *tbf) LOGP(DRLCMAC, LOGL_ERROR, "Software error: Pending uplink " "assignment. This may not happen, because the " "assignment message never gets transmitted. Please " - "be shure not to free in this state. PLEASE FIX!\n"); + "be sure not to free in this state. PLEASE FIX!\n"); if (tbf->dl_ass_state != GPRS_RLCMAC_DL_ASS_NONE) LOGP(DRLCMAC, LOGL_ERROR, "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!\n"); + "be sure not to free in this state. PLEASE FIX!\n"); tbf_timer_stop(tbf); while ((msg = msgb_dequeue(&tbf->llc_queue))) msgb_free(msg); @@ -802,9 +802,9 @@ int tbf_update(struct gprs_rlcmac_tbf *tbf) tbf_unlink_pdch(tbf); rc = bts->alloc_algorithm(ul_tbf, tbf, bts->alloc_algorithm_curst); - /* if no ressource */ + /* if no resource */ if (rc < 0) { - LOGP(DRLCMAC, LOGL_ERROR, "No ressource after update???\n"); + LOGP(DRLCMAC, LOGL_ERROR, "No resource after update???\n"); return -rc; } diff --git a/src/gprs_rlcmac.h b/src/gprs_rlcmac.h index 71ff608..fbae677 100644 --- a/src/gprs_rlcmac.h +++ b/src/gprs_rlcmac.h @@ -99,7 +99,7 @@ extern struct gprs_rlcmac_bts *gprs_rlcmac_bts; enum gprs_rlcmac_tbf_state { GPRS_RLCMAC_NULL = 0, /* new created TBF */ GPRS_RLCMAC_ASSIGN, /* wait for downlink assignment */ - GPRS_RLCMAC_FLOW, /* RLC/MAC flow, ressource needed */ + GPRS_RLCMAC_FLOW, /* RLC/MAC flow, resource needed */ GPRS_RLCMAC_FINISHED, /* flow finished, wait for release */ GPRS_RLCMAC_WAIT_RELEASE,/* wait for release or restart of DL TBF */ GPRS_RLCMAC_RELEASING, /* releasing, wait to free TBI/USF */ diff --git a/src/gprs_rlcmac_data.cpp b/src/gprs_rlcmac_data.cpp index 2f67bd0..b56d63d 100644 --- a/src/gprs_rlcmac_data.cpp +++ b/src/gprs_rlcmac_data.cpp @@ -220,7 +220,7 @@ uplink_request: /* create new TBF, use sme TRX as DL TBF */ tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, tbf->trx, tbf->first_ts); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ break; } @@ -228,7 +228,7 @@ uplink_request: ul_tbf = tbf_alloc(tbf, GPRS_RLCMAC_UL_TBF, tfi, trx, ts, tbf->ms_class, 0); if (!ul_tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ break; } @@ -269,7 +269,7 @@ uplink_request: } tlli = tbf->tlli; } - LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet ressource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); + LOGP(DRLCMAC, LOGL_ERROR, "RX: [PCU <- BTS] %s TFI: %u TLLI: 0x%08x FIXME: Packet resource request\n", (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", tbf->tfi, tbf->tlli); break; default: LOGP(DRLCMAC, LOGL_NOTICE, "RX: [PCU <- BTS] unknown control block received\n"); @@ -838,14 +838,14 @@ int gprs_rlcmac_rcv_rach(uint8_t ra, uint32_t Fn, int16_t qta) // Create new TBF tfi = tfi_alloc(GPRS_RLCMAC_UL_TBF, &trx, &ts, -1, -1); if (tfi < 0) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } /* set class to 0, since we don't know the multislot class yet */ tbf = tbf_alloc(NULL, GPRS_RLCMAC_UL_TBF, tfi, trx, ts, 0, 1); if (!tbf) { - LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH ressource\n"); + LOGP(DRLCMAC, LOGL_NOTICE, "No PDCH resource\n"); /* FIXME: send reject */ return -EBUSY; } diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp index f6af9b7..83a89ac 100644 --- a/src/gprs_rlcmac_sched.cpp +++ b/src/gprs_rlcmac_sched.cpp @@ -90,7 +90,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, ul_ass_tbf = tbf; } - /* check uplink ressource for polling */ + /* check uplink resource for polling */ if (poll_tbf) { LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: TRX=%d " "TS=%d FN=%d block_nr=%d scheduling free USF for " @@ -99,17 +99,17 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, (tbf->direction == GPRS_RLCMAC_UL_TBF) ? "UL" : "DL", poll_tbf->tfi); /* use free USF */ - /* else, we search for uplink ressource */ + /* else, we search for uplink resource */ } else { - /* select uplink ressource */ + /* select uplink resource */ for (i = 0, tfi = pdch->next_ul_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { tbf = pdch->ul_tbf[tfi]; /* no TBF for this tfi, go next */ if (!tbf) continue; - /* no UL ressources needed, go next */ - /* we don't need to give ressources in FINISHED state, + /* no UL resources needed, go next */ + /* we don't need to give resources in FINISHED state, * because we have received all blocks and only poll * for packet control ack. */ if (tbf->state != GPRS_RLCMAC_FLOW) @@ -119,9 +119,9 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, usf = tbf->dir.ul.usf[ts]; LOGP(DRLCMACSCHED, LOGL_DEBUG, "Received RTS for PDCH: " "TRX=%d TS=%d FN=%d block_nr=%d scheduling " - "USF=%d for required uplink ressource of " + "USF=%d for required uplink resource of " "UL TBF=%d\n", trx, ts, fn, block_nr, usf, tfi); - /* next TBF to handle ressource is the next one */ + /* next TBF to handle resource is the next one */ pdch->next_ul_tfi = (tfi + 1) & 31; break; } @@ -160,7 +160,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, /* Prio 2: select data message for downlink */ if (!msg) { - /* select downlink ressource */ + /* select downlink resource */ for (i = 0, tfi = pdch->next_dl_tfi; i < 32; i++, tfi = (tfi + 1) & 31) { tbf = pdch->dl_tbf[tfi]; @@ -170,7 +170,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, /* no DL TBF, go next */ if (tbf->direction != GPRS_RLCMAC_DL_TBF) continue; - /* no DL ressources needed, go next */ + /* no DL resources needed, go next */ if (tbf->state != GPRS_RLCMAC_FLOW && tbf->state != GPRS_RLCMAC_FINISHED) continue; @@ -178,7 +178,7 @@ int gprs_rlcmac_rcv_rts_block(uint8_t trx, uint8_t ts, uint16_t arfcn, LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling data " "message at RTS for DL TBF=%d (TRX=%d, " "TS=%d)\n", tfi, trx, ts); - /* next TBF to handle ressource is the next one */ + /* next TBF to handle resource is the next one */ pdch->next_dl_tfi = (tfi + 1) & 31; /* generate DL data block */ msg = gprs_rlcmac_send_data_block_acknowledged(tbf, fn, diff --git a/src/tbf.txt b/src/tbf.txt index eab58ba..025e56c 100644 --- a/src/tbf.txt +++ b/src/tbf.txt @@ -118,7 +118,7 @@ Control TS: Polling: In order to poll uplink control block from MS, a special poll state and frame number is stored at TBF. The scheduler reads that value and will not - assign uplink ressource for other TBFs at that frame number. + assign uplink resource for other TBFs at that frame number. When there is no uplink transmission received on the block, a timeout is indicated by layer 1 interface. There are two ways of checking timeout: -- 1.7.10.4

2 1

git tree / branches / ancestor?
by Harald Welte 11 Jul '12

11 Jul '12

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)

3 2

bug in common/oml.c of osmo-bts?
by Andreas Eversberg 10 Jul '12

10 Jul '12

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

2 1

TBF acknowledged mode is now working
by jolly 06 Jul '12

06 Jul '12

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

3 4

Re: osmo-pcu.git branch jolly updated. f3d060c6310bfa979225b871ba463284d3cda887
by Alexander Chemeris 05 Jul '12

05 Jul '12

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

1 0

Re: osmo-pcu.git branch master updated. c7e7f6868b6f24346424dee904f4e76d3f216ff4
by Alexander Chemeris 30 Jun '12

30 Jun '12

Hi Ivan, Any reasons why this can't be done without bits hand-coding? diff --git a/src/gprs_rlcmac.cpp b/src/gprs_rlcmac.cpp index 17120f9..711fb61 100644 --- a/src/gprs_rlcmac.cpp<http://cgit.osmocom.org/cgit/osmo-pcu/tree/src/gprs_rlcmac.cpp?id=bbbd79d6f…> +++ b/src/gprs_rlcmac.cpp<http://cgit.osmocom.org/cgit/osmo-pcu/tree/src/gprs_rlcmac.cpp?id=c7e7f6868…> @@ -718,6 +718,35 @@ int write_immediate_assignment(bitvec * dest, uint8_t downlink, uint8_t ra, uint return wp/8; } +int write_paging_request(bitvec * dest, uint8_t *ptmsi, uint16_t ptmsi_len) +{ + unsigned wp = 0; + + bitvec_write_field(dest, wp,0x0,4); // Skip Indicator + bitvec_write_field(dest, wp,0x6,4); // Protocol Discriminator + bitvec_write_field(dest, wp,0x21,8); // Paging Request Message Type + + bitvec_write_field(dest, wp,0x0,4); // Page Mode + bitvec_write_field(dest, wp,0x0,4); // Channel Needed + + // Mobile Identity + bitvec_write_field(dest, wp,ptmsi_len+1,8); // Mobile Identity length + bitvec_write_field(dest, wp,0xf,4); // unused + bitvec_write_field(dest, wp,0x4,4); // PTMSI type + for (int i = 0; i < ptmsi_len; i++) + { + bitvec_write_field(dest, wp,ptmsi[i],8); // PTMSI + } + bitvec_write_field(dest, wp,0x0,1); // "L" NLN(PCH) = off + bitvec_write_field(dest, wp,0x0,1); // "L" Priority1 = off + bitvec_write_field(dest, wp,0x1,1); // "L" Priority2 = off + bitvec_write_field(dest, wp,0x0,1); // "L" Group Call information = off + bitvec_write_field(dest, wp,0x0,1); // "H" Packet Page Indication 1 = packet paging procedure + bitvec_write_field(dest, wp,0x1,1); // "H" Packet Page Indication 2 = packet paging procedure + bitvec_write_field(dest, wp,0x3,2); // spare padding + return wp/8; +} + void write_packet_uplink_ack(RlcMacDownlink_t * block, uint8_t tfi, uint32_t tlli, uint8_t fi, uint8_t bsn) { // Packet Uplink Ack/Nack TS 44.060 11.2.28 On Fri, Jun 29, 2012 at 7:54 PM, 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 c7e7f6868b6f24346424dee904f4e76d3f216ff4 (commit) > via bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 (commit) > from 34460b84072e7ec4c1bafe502aa9d6d859858c0a (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=c7e7f6868b6f24346424dee904… > > 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. > > > http://cgit.osmocom.org/cgit/osmo-pcu/commit/?id=bbbd79d6f1abd4e7f865f72c15… > > commit bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 > Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com> > Date: Fri Jun 29 20:30:10 2012 +0400 > > Fixed DL TBF establishment on CCCH. > We shouldn't use paging procedure for DL TBF establishment, if we > didn't receive paging message from BSSGP. > > ----------------------------------------------------------------------- > > Summary of changes: > src/gprs_bssgp_pcu.cpp | 34 +++++++++++++++--------------- > src/gprs_rlcmac.cpp | 54 > +++++++++++++++++++++++++++++++++++++---------- > src/gprs_rlcmac.h | 3 +- > src/pcu_l1_if.cpp | 11 +++++++++ > src/pcu_l1_if.h | 1 + > 5 files changed, 73 insertions(+), 30 deletions(-) > > > hooks/post-receive > -- > UNNAMED PROJECT > > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

Problems with understanding packet downlink assignment
by jolly 28 Jun '12

28 Jun '12

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

2 1

Re: osmo-pcu.git branch jolly updated. 7d7cf54f39b9136749d47336576688ce150be49d
by Alexander Chemeris 25 Jun '12

25 Jun '12

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

1 0

Fwd: ready-to-send at osmo-pcu
by Ivan Kluchnikov 20 Jun '12

20 Jun '12

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

1 0

ready-to-send at osmo-pcu
by Andreas Eversberg 18 Jun '12

18 Jun '12

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

2 1

Re: osmo-pcu.git branch master updated. a9e6dc5084627e7c279ba08de7a7809e97ebc539
by Alexander Chemeris 17 Jun '12

17 Jun '12

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

1 0

Re: New PCU repository
by Holger Hans Peter Freyther 16 Jun '12

16 Jun '12

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

3 3

Re: New PCU repository
by Harald Welte 16 Jun '12

16 Jun '12

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)

1 0

New PCU repository
by Harald Welte 14 Jun '12

14 Jun '12

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)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs