From laforge at gnumonks.org Thu Jun 14 13:24:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 14 Jun 2012 21:24:05 +0800 Subject: New PCU repository In-Reply-To: References: Message-ID: <20120614132405.GC7050@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From hfreyther at sysmocom.de Sat Jun 16 08:25:41 2012 From: hfreyther at sysmocom.de (Holger Hans Peter Freyther) Date: Sat, 16 Jun 2012 10:25:41 +0200 Subject: New PCU repository In-Reply-To: References: <20120614132405.GC7050@prithivi.gnumonks.org> Message-ID: <20120616082541.GD8283@sangmingze.sysmocom.de> 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 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 laforge at gnumonks.org Sat Jun 16 08:23:48 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jun 2012 16:23:48 +0800 Subject: New PCU repository In-Reply-To: References: <20120614132405.GC7050@prithivi.gnumonks.org> Message-ID: <20120616082348.GD6697@prithivi.gnumonks.org> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Sat Jun 16 08:35:34 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 16 Jun 2012 12:35:34 +0400 Subject: New PCU repository In-Reply-To: <20120616082541.GD8283@sangmingze.sysmocom.de> References: <20120614132405.GC7050@prithivi.gnumonks.org> <20120616082541.GD8283@sangmingze.sysmocom.de> Message-ID: Hi Holger, That's fine for external patches, but we usually review internal commits as well. I think the easiest way is to create a github mirror and use its facilities fit sending emails and reviewing. I just have to learn how to setup this mirroring. Sent from my Android device. -- Regards, Alexander Chemeris CEO, Fairwaves LLC http://fairwaves.ru 16.06.2012 12:25 ???????????? "Holger Hans Peter Freyther" < hfreyther at sysmocom.de> ???????: > 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 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: From pablo at gnumonks.org Sat Jun 16 19:51:34 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 16 Jun 2012 21:51:34 +0200 Subject: New PCU repository In-Reply-To: <20120616082541.GD8283@sangmingze.sysmocom.de> References: <20120614132405.GC7050@prithivi.gnumonks.org> <20120616082541.GD8283@sangmingze.sysmocom.de> Message-ID: <20120616195134.GA20425@1984> On Sat, Jun 16, 2012 at 10:25:41AM +0200, Holger Hans Peter Freyther wrote: > 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? Don't know if this is exactly what you need, I've been using "patchwork" for some time: http://ozlabs.org/~jk/projects/patchwork/ It's relatively easy to deploy and it provides a list of pending patches. It's being used by several FOSS projects regarding Linux: http://patchwork.ozlabs.org/ In general, I think it's a good practise to send patches first to the mailing list for review before committing them in projects. If nobody complains, apply it. It also forces you to produce good patchsets, ie. contributions splitted into logical pieces with good changelog descriptions that people can track. This can probably be too much overhead if the amount of people contributing to this is relatively small and the amount of contributed changes is relatively. From alexander.chemeris at gmail.com Sat Jun 16 19:59:06 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 16 Jun 2012 23:59:06 +0400 Subject: New PCU repository In-Reply-To: <20120616195134.GA20425@1984> References: <20120614132405.GC7050@prithivi.gnumonks.org> <20120616082541.GD8283@sangmingze.sysmocom.de> <20120616195134.GA20425@1984> Message-ID: On Sat, Jun 16, 2012 at 11:51 PM, Pablo Neira Ayuso wrote: > On Sat, Jun 16, 2012 at 10:25:41AM +0200, Holger Hans Peter Freyther wrote: >> 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? > > Don't know if this is exactly what you need, I've been using > "patchwork" for some time: > > http://ozlabs.org/~jk/projects/patchwork/ > > It's relatively easy to deploy and it provides a list of pending > patches. > > It's being used by several FOSS projects regarding Linux: > > http://patchwork.ozlabs.org/ > > In general, I think it's a good practise to send patches first to the > mailing list for review before committing them in projects. If nobody > complains, apply it. It also forces you to produce good patchsets, ie. > contributions splitted into logical pieces with good changelog > descriptions that people can track. > > This can probably be too much overhead if the amount of people > contributing to this is relatively small and the amount of contributed > changes is relatively. Yes, I think it's too much overhead in our case. But thank you for the link anyway - the tool looks interesting. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Sun Jun 17 09:51:54 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 17 Jun 2012 13:51:54 +0400 Subject: osmo-pcu.git branch master updated. a9e6dc5084627e7c279ba08de7a7809e97ebc539 In-Reply-To: References: Message-ID: 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 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=a9e6dc5084627e7c279ba08de7a7809e97ebc539 > > commit a9e6dc5084627e7c279ba08de7a7809e97ebc539 > Author: Ivan Kluchnikov > 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 From andreas at eversberg.eu Mon Jun 18 17:19:30 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 18 Jun 2012 19:19:30 +0200 Subject: ready-to-send at osmo-pcu Message-ID: <4FDF6322.7080702@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 From andreas at eversberg.eu Mon Jun 18 17:19:30 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 18 Jun 2012 19:19:30 +0200 Subject: ready-to-send at osmo-pcu Message-ID: <4FDF6322.7080702@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 From alexander.chemeris at gmail.com Mon Jun 18 19:26:18 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 18 Jun 2012 23:26:18 +0400 Subject: ready-to-send at osmo-pcu In-Reply-To: <4FDF6322.7080702@eversberg.eu> References: <4FDF6322.7080702@eversberg.eu> Message-ID: Andreas, On Mon, Jun 18, 2012 at 9:19 PM, Andreas Eversberg wrote: > 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. Logic looks reasonable for me. If Ivan doesn't see any pitfalls, I'm ok with this. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From Ivan.Kluchnikov at fairwaves.ru Wed Jun 20 09:16:14 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Wed, 20 Jun 2012 13:16:14 +0400 Subject: Fwd: ready-to-send at osmo-pcu In-Reply-To: References: <4FDF6322.7080702@eversberg.eu> Message-ID: 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Mon Jun 25 08:34:07 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 25 Jun 2012 10:34:07 +0200 Subject: osmo-pcu.git branch jolly updated. 7d7cf54f39b9136749d47336576688ce150be49d In-Reply-To: References: Message-ID: 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 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=7d7cf54f39b9136749d47336576688ce150be49d > > commit 7d7cf54f39b9136749d47336576688ce150be49d > Author: Andreas Eversberg > 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 From alexander.chemeris at gmail.com Mon Jun 25 08:34:07 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 25 Jun 2012 10:34:07 +0200 Subject: osmo-pcu.git branch jolly updated. 7d7cf54f39b9136749d47336576688ce150be49d In-Reply-To: References: Message-ID: 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 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=7d7cf54f39b9136749d47336576688ce150be49d > > commit 7d7cf54f39b9136749d47336576688ce150be49d > Author: Andreas Eversberg > 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 From andreas at eversberg.eu Thu Jun 28 12:52:32 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 28 Jun 2012 14:52:32 +0200 Subject: Problems with understanding packet downlink assignment Message-ID: <4FEC5390.50706@eversberg.eu> 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 From andreas at eversberg.eu Thu Jun 28 12:52:32 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 28 Jun 2012 14:52:32 +0200 Subject: Problems with understanding packet downlink assignment Message-ID: <4FEC5390.50706@eversberg.eu> 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 From Ivan.Kluchnikov at fairwaves.ru Thu Jun 28 13:43:17 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Thu, 28 Jun 2012 17:43:17 +0400 Subject: Problems with understanding packet downlink assignment In-Reply-To: <4FEC5390.50706@eversberg.eu> References: <4FEC5390.50706@eversberg.eu> Message-ID: Hi, Andreas! I am not sure that I understand question. I think, if downlink assignment got lost (no response from mobile to polling of downlink acknowledgement), we should try to establish this TBF again (repeat downlink assignment), after that we should transmit in established TBF all LLC PDUs recieved from SGSN . 2012/6/28 jolly > 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 > > > > > -- Regards, Ivan Kluchnikov. http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jun 30 08:34:51 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 30 Jun 2012 09:34:51 +0100 Subject: osmo-pcu.git branch master updated. c7e7f6868b6f24346424dee904f4e76d3f216ff4 In-Reply-To: References: Message-ID: 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 +++ b/src/gprs_rlcmac.cpp @@ -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 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=c7e7f6868b6f24346424dee904f4e76d3f216ff4 > > commit c7e7f6868b6f24346424dee904f4e76d3f216ff4 > Author: Ivan Kluchnikov > 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=bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 > > commit bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 > Author: Ivan Kluchnikov > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jun 30 08:34:51 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 30 Jun 2012 09:34:51 +0100 Subject: osmo-pcu.git branch master updated. c7e7f6868b6f24346424dee904f4e76d3f216ff4 In-Reply-To: References: Message-ID: 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 +++ b/src/gprs_rlcmac.cpp @@ -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 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=c7e7f6868b6f24346424dee904f4e76d3f216ff4 > > commit c7e7f6868b6f24346424dee904f4e76d3f216ff4 > Author: Ivan Kluchnikov > 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=bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 > > commit bbbd79d6f1abd4e7f865f72c15878e0f32f252c3 > Author: Ivan Kluchnikov > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: