Re: [Openlte-discuss] decoding SIB1
An open source 3GPP LTE implementation.
Status: Alpha
Brought to you by:
bwojtowi
Menu
▾
▴
Re: [Openlte-discuss] decoding SIB1
|
From: <vma...@te...> - 2013-03-25 13:16:04
|
Great! Thanks Ben. Also, just to confirm, a "Cell barred = 1" in the OpenLTE output means that the cell is not barred, correct? Regards, -Victor El Do 24/03/13 20:06, Ben Wojtowicz <bwo...@gm...> escribió: Victor, I released V00.08.01 last week with fixes for the SIB1 decoding issues in lte_fdd_dl_receive.m. Try it out and let me know if you are still having issues. Thanks, Ben On Mon, Mar 4, 2013 at 8:49 PM, Ben Wojtowicz <bwo...@gm...> wrote: Victor, I just noticed that this was off the list. Not sure when that happened, but let's keep this conversation on list. The PDSCH decoding is very reliable as the final step is a CRC check. If there is a problem with what is reported, I would expect it to be with the parsing. There are dissectors available in Wireshark if you want to verify that all the fields are correct. If the reported data is correct, I would expect that several (maybe 6) PCIs should be present in SIB4, and only a few should actually be decoded. And I could imagine cases where PCIs are decoded that are not reported in SIB4. Hope this helps, Ben On Sun, Mar 3, 2013 at 10:30 PM, <vma...@te...> wrote: Ben, Thanks for looking in this. Also, perhaps you could give me some insight into the following question. The SIB4 decoded below indicates that the physical address of the neighboring cell is 64. However, by using the Cell Specific Reference signals for synchronization, I was able to decode that in addition to physical cell ID 145, cell IDs 144 and 146 were located nearby. Now, the reference signals for Cell ID 64 would be located in the same frequencies as Cell ID 145 and that could explain why I did not decoded Cell ID 64 using the reference signals only (they would also have lower power than those of Cell ID 145). My question is, how reliable is SIB4 in indicating the physical addresses of the neighboring cells given that it does not list Cell IDs 144 and 145? Thanks again, -Victor El Lu 04/03/13 03:10, Ben Wojtowicz <bwo...@gm...> escribió: Victor, Sorry for the delay, but I just tried decoding the data you provided with the file scanner (V00.08.00) and it decoded. Here is the decoded output: DL LTE Channel found [0]: MIB Decoded: Frequency Offset = -1.53 System Frame Number = 255 Physical Cell ID = 145 Number of TX Antennas = 2 Bandwidth = 10MHz PHICH Duration = Normal PHICH Resource = 1 SIB1 Decoded: PLMN Identity List: 311-480, Verizon, not reserved for operator use Tracking Area Code = 18432 Cell Identity = 18523906 Cell Barred = Not Barred Intra Frequency Reselection = Allowed CSG Indication = FALSE Q Rx Lev Min = -120dBm Q Rx Lev Min Offset = 8dB P Max = 23dBm Frequency Band = 13 SI Window Length = 20ms Scheduling Info List: SI Periodicity = 16 frames SI Window Starts at N_subframe = 0, SFN mod 16 = 0 SIB Type = 2 SIB Type = 3 SI Periodicity = 64 frames SI Window Starts at N_subframe = 0, SFN mod 64 = 2 SIB Type = 4 SIB Type = 8 Duplexing Mode = FDD SI Value Tag = 19 SIB4 Decoded: List of intra-frequency neighboring cells: Physical Cell ID = 64 Q Offset Range = 3dB SIB8 Decoded: Search Window Size = 10 Pre Registration = Not Allowed Band Class List: Band Class = 0 Cell Reselection Priority = 2 Threshold X High = 16 Threshold X Low = 14 Neighbor Cell List: Band Class = 0 Neighbor Cells Per Frequency List ARFCN = 630 Phys Cell ID List 216 48 384 40 376 212 T Reselection = 5s T-Reselection Scale Factor Medium = 0.25 T-Reselection Scale Factor High = 0.25 DCI 1C FOUND L = 4, 1 ERROR: DCI 1A flagged as DCI 0 PAGING MESSAGE RECEIVED: 01000000000000111001110001000000111000101001111010100000 DCI 1C FOUND L = 4, 1 DCI 1C FOUND L = 8, 0 DCI 1C FOUND L = 4, 3 DCI 1C FOUND L = 8, 0 PAGING MESSAGE RECEIVED: 01000000000000111001110011000000001100110001110001100000 DCI 1C FOUND L = 8, 0 PAGING MESSAGE RECEIVED: 01000000000000111000110011000000111011111101110100110000 SIB2 Decoded: Number of RACH Preambles = 56 Power Ramping Step = 6dB Preamble init target RX power = -104dBm Preamble TX Max = 3 RA Response Window Size = 5 Subframes MAC Contention Resolution Timer = 64 Subframes Max num HARQ TX for Message 3 = 3 Modification Period Coeff = 2 Default Paging Cycle = 128 Frames Modification Period = 256 Frames nB = 128 Frames Root Sequence Index = 1 PRACH Config Index = 4 Preamble Format = 0, RACH SFN = Any, RACH Subframe Number = 4 High Speed Flag = Unrestricted Set Ncs Configuration = 9 PRACH Freq Offset = 2 Reference Signal Power = 18dBm Pb = 1 Nsb = 1 Hopping Mode = Inter Subframe PUSCH Nrb Hopping Offset = 4 64QAM = Not Allowed Group Hopping = Enabled Group Assignment PUSCH = 0 Sequence Hopping = Disabled Cyclic Shift = 0 Delta PUCCH Shift = 2 N_rb_cqi = 1 N_cs_an = 0 N1 PUCCH AN = 6 SRS Bandwidth Config = 0 SRS Subframe Config = 0 Simultaneous AN and SRS = True SRS Max Up PTS = False P0 Nominal PUSCH = -82dBm Alpha = 0.8 P0 Nominal PUCCH = -114dBm Delta F PUCCH Format 1 = 0dB Delta F PUCCH Format 1B = 3dB Delta F PUCCH Format 2 = 0dB Delta F PUCCH Format 2A = 0dB Delta F PUCCH Format 2B = 0dB Delta Preamble Message 3 = 0dB UL CP Length = Normal T300 = 400ms T301 = 1500ms T310 = 1000ms N310 = 1 T311 = 5000ms N311 = 1 UL ARFCN = 23230 UL Bandwidth = 10MHz Additional Spectrum Emission = 1 Time Alignment Timer = 2560 Subframes I'll see if I can dig into what is wrong with the octave code and update it. Thanks, Ben On Wed, Feb 20, 2013 at 9:27 AM, <vma...@te...> wrote: Ben, I double checked, the collect is actually 1 sec worth of data. Best, -Victor El Mi 20/02/13 02:47, vma...@te... escribió: > > Ben, > > You can find the LTE data collect here: > http://dl.dropbox.com/u/105689861/LTE.mat > > It is 100 ms worth of data sampled at 30.72 MHz. > > I will try scanning it with gnuradio soon. > > Best, > > -Victor > > > El Lu 18/02/13 02:14, Ben Wojtowicz escribió: > Victor, > > The file scan gnuradio app is part of openLTE. You can follow the build instructions in the README file and then run it using LTE_fdd_dl_file_scan.py. > > For the upload, you could try a site like dropbox. > > Ben > > On Thu, Feb 14, 2013 at 10:31 AM, <vma...@te...> wrote: > > Ben, > > No, I have not used the scan gnuradio app. Do you know where I can find it? > > Also, is there a place where I can upload the file? It is 463 MB. > > Regards, > > -Victor > > El Mi 13/02/13 18:47, Ben Wojtowicz escribió: > > Victor,Im not sure if I have ever tried decoding with a PCFICH of 3, so there may be a bug. Also, have you tried running the file scan gnuradio app with this data? The octave code hasn't been kept up to date with all of the new changes to the gnuradio apps. If you dont mind, could you post the data file you are using? > > Thanks, > BenOn Feb 13, 2013 7:59 AM, <vma...@te...> wrote: > > Hello, I have collected some over the air data and used the OpenLTE scripts to try to decode the SIB1. > However, it seems that the script only decodes the PCFICH correctly since I obtain a value of 3 and that it breaks somewhere along the way before decoding the SIB1. The following is the output that I get after running OpenLTE on the collected data: > > Found PSS-1 in 26 (71.493915)Found SSS-48, 0 index is 196423, cell_id is 145Found BCH, N_ant = 2, N_rb_dl = 50, phich_duration = normal, phich_resource = 1, sfn = 854ERROR: SIB1 PDCCH NOT FOUND > > Does anybody have any ideas as to why I cannot decode the SIB1? > Best regards, > -Victor > > ------------------------------------------------------------------------------ > > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > > _______________________________________________ > Openlte-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openlte-discuss > > > > |
