Changes to MIB for Idle mode

Changes to MIB for Idle mode

[buherman, 2013-07-10 16:34:38]

Hi all,

I encountered some problems while working on initial cell selection. So I'm
looking for some feedback.

At first, I wanted to verify the existing MIB behaviour, because SIB1 will be
based on it. I was running some experiments with the existing MIB functionality,
then I became aware of the problems below:

1) If LteHelper::Attach is not called, UE cannot receive MIB. Apparently
LteHelper::Attach is the one initiating the UE to listen to the channel.

2) MIB from non-serving cells are ignored. Again, LteHelper::Attach is the one
setting the m_cellId variable.

3) In saturation mode, it's not possible to activate EPS bearer before
LteHelper::Attach is called.

So those are some dependencies with LteHelper::Attach that I have to change. I
have to make UE listen to the channel right away and also receive MIB from any
cell.

I'd like to discuss with you regarding what would be the best way to model this.
I've tried to deal with the problems by my own (I've uploaded it to Rietveld
[1]), so we can base the discussion on that. Problem 1) and 2) seem to be
solved, but I still have this uneasy feeling that this approach might be
considered as dirty, not standard, and prone to bugs.

Anyway, the changes in summary:

1) MIB is now more similar to PSS.
 - there's one flag which is set to true every 10 ms
 - there's a callback function to transfer MIB from LteSpectrumPhy to LteUePhy
 - MIB is still an LTE control message

2) If UE is not attached to any cell, then it will receive MIB from any cell.
But as soon as it is attached to one cell, then it will only receive MIB from
that cell.
 - this is because an MIB from different cell will trigger a change in bandwidth
configuration
 - and if that happens while the actual RX to the serving cell is not finished
yet, some errors might raise because the spectrum model of the UE has changed

3) Set UE PHY to initially use 6 RB bandwidth, EARFCN of 100, and 9.0 db noise
figure
 - this is done when the object is instantiated (i.e.
LteHelper::InstallSingleUeDevice)
 - also set the UE to listen to the downlink channel

Some limitations that I know so far:
 - MIB is no longer affected by error model (because it doesn't go through
EndRxDlCtrl anymore)
 - ideally, eNodeB and UE should have previous knowledge on a specific
channel/EARFCN where MIB is transmitted, but for now I just use the existing DL
channel and copy EARFCN of 100 from eNodeB attribute (later I have to consider
that the attribute value may change)

Do you think this approach is acceptable? Do you have a better idea, or any
suggestion?

While waiting for your feedback, I'll work on problem 3). Thanks in advance.

-budi-

[1] https://codereview.appspot.com/11061044/

[Marco Miozzo, 2013-07-11 10:16:32]

A quick feedback for what concern the MIB implementation, it is fine with me, I
would just confirm that we do not want any error model on this message, since it
seems to me it might populate the RRC tables of negligible eNB (consider the
case of dense deployment of small-cells), what's your feeling?
I also would have some feedback on some code movement which I did not get the
reason behind (see my comments in the code).
For what concern problem 3) I need more time.

[Marco Miozzo, 2013-07-11 10:16:40]

https://codereview.appspot.com/11061044/diff/1/src/lte/helper/lte-helper.cc
File src/lte/helper/lte-helper.cc (right):

https://codereview.appspot.com/11061044/diff/1/src/lte/helper/lte-helper.cc#n...
src/lte/helper/lte-helper.cc:332: ulPhy->SetChannel (m_uplinkChannel);
What is the reason of moving the SetChannel?
From code perspective it seems not so relevant.

https://codereview.appspot.com/11061044/diff/1/src/lte/model/lte-spectrum-phy.cc
File src/lte/model/lte-spectrum-phy.cc (left):

https://codereview.appspot.com/11061044/diff/1/src/lte/model/lte-spectrum-phy...
src/lte/model/lte-spectrum-phy.cc:760: if (dl)
What is the reason for moving this code after in the case?

[buherman, 2013-07-11 11:43:02]

Hi Marco, thanks a lot for the feedback. Please see my comments below.

Regards,
-budi-

On 2013/07/11 10:16:32, marco.miozzo wrote:
> A quick feedback for what concern the MIB implementation, it is fine with me,
I
> would just confirm that we do not want any error model on this message, since
it
> seems to me it might populate the RRC tables of negligible eNB (consider the
> case of dense deployment of small-cells), what's your feeling?
> I also would have some feedback on some code movement which I did not get the
> reason behind (see my comments in the code).
> For what concern problem 3) I need more time.

I'm sorry but I'm not sure where are the RRC tables that you mentioned?

But anyway, I do feel worry about the impact to performance, because MIB from
cells far far away will still be captured by the UE. By receiving an MIB, UE
will update its bandwidth. I haven't tried this, but I suspect if I increase the
number of eNodeBs in the test script to 100, then the UE will change bandwidth
100 times at every 10 ms. :(

At the moment I have 2 ideas to cut this down (but not yet implemented):

1) Have a flag like m_isMibReceived in Spectrum PHY, so that the MIB callback
function is only called once in every subframe.

2) When UE RRC receives the MIB, the call to SetDlBandwidth will be limited to
only the occasions where the MIB's bandwidth != the current UE's bandwidth.

https://codereview.appspot.com/11061044/diff/1/src/lte/helper/lte-helper.cc
File src/lte/helper/lte-helper.cc (right):

https://codereview.appspot.com/11061044/diff/1/src/lte/helper/lte-helper.cc#n...
src/lte/helper/lte-helper.cc:332: ulPhy->SetChannel (m_uplinkChannel);
On 2013/07/11 10:16:40, marco.miozzo wrote:
> What is the reason of moving the SetChannel?
> From code perspective it seems not so relevant.

I copied some code from DoSynchronizeWithEnb to the LteUePhy constructor, so
that the UE will immediately join the channel and listen for MIB. This code
assumes that Spectrum PHY has already properly tied to the channel.

That's why I changed the order of this code (setting up the channel in Spectrum
PHY) so that it runs before the PHY is instantiated. I first changed it in
InstallSingleUeDevice, but then also did the same to InstallSingleEnbDevice just
so that it looks consistent.

https://codereview.appspot.com/11061044/diff/1/src/lte/model/lte-spectrum-phy.cc
File src/lte/model/lte-spectrum-phy.cc (left):

https://codereview.appspot.com/11061044/diff/1/src/lte/model/lte-spectrum-phy...
src/lte/model/lte-spectrum-phy.cc:760: if (dl)
On 2013/07/11 10:16:40, marco.miozzo wrote:
> What is the reason for moving this code after in the case?

The `if (cellId == m_cellId)` block will schedule an EndRxDlCtrl at time (now +
duration). Similarly, I also need to schedule the MIB callback function at time
(now + duration). When I keep the order of these two blocks as before, then ns-3
would run the MIB callback function first, and then the EndRxDlCtrl later. What
happened when I tried it is that the MIB callback function triggered an update
to the UE's DL bandwidth. Apparently this also changed the PSD of the Spectrum
PHY, and this hit an ASSERT in EndRxDlCtrl (probably because the number of RB is
no longer the same).

I suppose it's better to change the bandwidth after RX is finished. That's why I
changed the order of those 2 blocks. Even though they're still scheduled for the
same time, but EndRxDlCtrl enters the ns-3 scheduling queue first, so it will be
executed by ns-3 first.

Is it dangerous to assume this FIFO behaviour of ns-3?

[Nicola Baldo, 2013-07-11 11:44:20]

Hi Budi,

I still did not look at the code, however I have one general comment. To my
understanding:

1) multiple PSSs and SSSs can be detected in parallel by the PHY, as the
detection does not require synchronization
2) decoding the PBCH requires synchronization, hence a typical UE implementation
will decode a PBCH from a single cell at a time

I think this is confirmed for example by the description of " Initial
synchronization" in Sesia's "LTE from theory to practice", section 7.2

With this in mind, please see my detailed comments below:

On 2013/07/10 16:34:38, buherman wrote:
> 
> 1) If LteHelper::Attach is not called, UE cannot receive MIB. Apparently
> LteHelper::Attach is the one initiating the UE to listen to the channel.

the UE can detect the strongest cell anyway based on the cellid and the
corresponding measurement when detecting the PSSs.
Then it would synchronize to that cellid, calling
LteUeCphySap::SyncronizeWithEnb. After this, it would decode the MIB for that
cellid only.

> 
> 2) MIB from non-serving cells are ignored. 

I think this is ok. Do you have any argument for changing this behavior?


> Again, LteHelper::Attach is the one
> setting the m_cellId variable.

when idle cell selection is being used, I'd say it's the LteUeRrc that is in
charge of setting the cellid


> 
> 3) In saturation mode, it's not possible to activate EPS bearer before
> LteHelper::Attach is called.

did you consider that LteHelper::ActivateDataRadioBearer is to be used instead
of ActivateEpsBearer when the non-EPC saturation mode is used?
Anyway, I'd restrict the non-EPC mode to the use of LteHelper::Attach () only -
i.e., no idle cell selection support.

[buherman, 2013-07-11 14:16:35]

Thanks, Nicola. Please see my comments inline below.

On 2013/07/11 11:44:20, Nicola Baldo wrote:
> 1) multiple PSSs and SSSs can be detected in parallel by the PHY, as the
> detection does not require synchronization
> 2) decoding the PBCH requires synchronization, hence a typical UE
implementation
> will decode a PBCH from a single cell at a time
> 
> I think this is confirmed for example by the description of " Initial
> synchronization" in Sesia's "LTE from theory to practice", section 7.2

Thanks for the pointer. Now I realize that I've probably made several wrong
assumptions. But I'm still not clear enough...

> the UE can detect the strongest cell anyway based on the cellid and the
> corresponding measurement when detecting the PSSs.
> Then it would synchronize to that cellid, calling
> LteUeCphySap::SyncronizeWithEnb. After this, it would decode the MIB for that
> cellid only.

I'm confused here, does synchronize also mean that the UE camps to that cell?

> > 2) MIB from non-serving cells are ignored. 
> 
> I think this is ok. Do you have any argument for changing this behavior?

My previous understanding is that UE should be able to receive MIB (and SIB1,
and maybe SIB2 too?) before it camps to a cell. So I thought MIB from
non-serving cells should not be ignored. But now I'm not so sure about this
anymore.

> > Again, LteHelper::Attach is the one
> > setting the m_cellId variable.
> 
> when idle cell selection is being used, I'd say it's the LteUeRrc that is in
> charge of setting the cellid

Yes, I agree.

> > 3) In saturation mode, it's not possible to activate EPS bearer before
> > LteHelper::Attach is called.
> 
> did you consider that LteHelper::ActivateDataRadioBearer is to be used instead
> of ActivateEpsBearer when the non-EPC saturation mode is used?

Yes, I did. What I meant here by "to activate EPS bearer" is the
LteHelper::ActivateDataRadioBearer. Sorry for the confusion.

> Anyway, I'd restrict the non-EPC mode to the use of LteHelper::Attach () only
-
> i.e., no idle cell selection support.

I see. I can first concentrate on the EPC mode, and deal with non-EPC mode later
if deemed necessary.

[Nicola Baldo, 2013-07-11 15:30:03]

On 2013/07/11 14:16:35, buherman wrote:
> On 2013/07/11 11:44:20, Nicola Baldo wrote:
> > the UE can detect the strongest cell anyway based on the cellid and the
> > corresponding measurement when detecting the PSSs.
> > Then it would synchronize to that cellid, calling
> > LteUeCphySap::SyncronizeWithEnb. After this, it would decode the MIB for
that
> > cellid only.
> 
> I'm confused here, does synchronize also mean that the UE camps to that cell?

"camped on" is an AS/RRC state, and "synchronized" is a
PHY state. I think one does not necessarily imply the other; for
example, it is different whether it's an initial cell selection, or a
cell selection based on stored System Information.

I found some more references for initial cell selection in the 3GPP
specs, I hope that they shed some light on this:

--- TS 36.300, 10.1.1.1  Cell selection ---

 - The UE NAS layer identifies a selected PLMN and equivalent PLMNs;
 - The UE searches the E-UTRA frequency bands and for each carrier
   frequency identifies the strongest cell. It reads cell system
   information broadcast to identify its PLMN(s) [..]
 - The UE seeks to identify a suitable cell; if it is not able to
   identify a suitable cell it seeks to identify an acceptable
   cell. When a suitable cell is found or if only an acceptable cell
   is found it camps on that cell and commence the cell reselection procedure


--- TS 36.304, section 5.2.3.1
 
a) Initial Cell Selection
This procedure requires no prior knowledge of which RF channels are E-UTRA
carriers. The UE shall scan
all RF channels in the E-UTRA bands according to its capabilities to find a
suitable cell. On each carrier
frequency, the UE need only search for the strongest cell. Once a suitable cell
is found this cell shall be
selected.



> > > 2) MIB from non-serving cells are ignored. 
> > 
> > I think this is ok. Do you have any argument for changing this behavior?
> 
> My previous understanding is that UE should be able to receive MIB (and SIB1,
> and maybe SIB2 too?) before it camps to a cell. 

I agree, at least for initial cell selection (no stored system information)

> So I thought MIB from
> non-serving cells should not be ignored. 

to receive the MIB from another cell, the UE should synchronize (which does not
mean camp!) with that cell. 

Note anyway that the specs only mandate that the UE reads the system
information of the strongest cell per carrier frequency.

[buherman, 2013-07-12 19:15:57]

Hi Nicola,

Thanks again for the clarification. I've also been browsing the Internet for
more information. Somehow they're like scattered pieces to me, so I need a
little bit more time to rethink and rearrange the puzzles. I'll be back on
Monday or Tuesday with a draft/prototype and some questions.

Regards,
-budi-

[jaime.ferragut_cttc.es, 2013-07-15 09:21:21]

Hi all,

Apologies for the delay, but I was busy with a paper deadline.

Looks like everything is much clearer now after the e-mail exchange. 
Nevertheless, here's my two cents:

> "camped on" is an AS/RRC state, and "synchronized" is a
> PHY state. I think one does not necessarily imply the other; for
> example, it is different whether it's an initial cell selection, or a
> cell selection based on stored System Information.
Correct. In Initial Cell Selection, the UE decodes the PBCH after 
detecting the synchronization signals. Since the system information is 
common to all cells, a UE does not need to decode the PBCH for neighbour 
cell detection.

> to receive the MIB from another cell, the UE should synchronize (which
> does not mean camp!) with that cell.
>
> Note anyway that the specs only mandate that the UE reads the system
> information of the strongest cell per carrier frequency.
>
Correct. Essentially, the Inicial Cell Selection flow would be as follows:

1) Detect cells with {PSS,SSS}
2) Synchronize and decode PBCH for strongest cell in carrier frequency
3) Read system information from {MIB,SIB1}
4) Detect neighbour cells with {PSS,SSS} and already acquired system 
information



Cheers,

Jaime.-

[buherman, 2013-07-16 08:23:21]

Thanks, Jaime. I get better understanding now, but still hope that I don't miss
anything.

Hi all,

I've updated the same Rietveld issue with a new patchset based on my
interpretation of our email discussion. You won't see the previous patchset in
the diff of this patchset, because I'd consider the previous one discarded.

I'm summarizing the second patchset as follow:

--- UE PHY ---

1) Starts by attaching itself to the channel, listening to 6 RBs for PSS, but
not synchronized to any particular cell. Thus PSS is the only signal it can
listen to.

2) Has 3 states: CELL_SEARCH, DECODING_BCH, and ATTACHED.

3) Starting from CELL_SEARCH, UE collects the PSS and use them on UE
measurements' layer 1 filtering, so an averaged set of RSRP will be produced
after every 200 ms. At this point, UE will choose the strongest one, synchronize
to it, and switch to DECODING_BCH state.

4) In DECODING_BCH state, UE will start to receive MIB and SIB1 from a
particular cell. These two messages are simply relayed to RRC.

--- UE RRC ---

5) When RRC has received both MIB and SIB1 from a cell and its state is still
IDLE_CELL_SELECTION, it starts the initial cell selection procedure.

6) When it fails (e.g. because of incompatible PLMN/CSG), RRC tells PHY to retry
the cell search. This is done by a new function RetryCellSearch in CPHY SAP. PHY
will switch back to CELL_SEARCH state and retry the cell search procedure (point
#3 above) while avoiding the previous cell (there's an std::set in PHY to keep
track which cells have been tried).

7) If successful, RRC tells PHY to switch to ATTACHED state (by calling the new
function Attach in CPHY SAP) and RRC camps to that cell (RRC state switches to
IDLE_CAMPED_NORMALLY).

8) There's a limit of how many retries can be done, and I put it as an attribute
of UE RRC. If the limit is exceeded, RRC simply stops calling RetryCellSearch,
so it will stay in IDLE_CELL_SELECTION for the rest of the simulation (unless
someone calls LteHelper::Attach on it).

--- MIB and SIB1 ---

9) New LTE control message for SIB1, which will be sent periodically by eNodeB
PHY.

10) Removed all functions for sending and receiving MIB and SIB1 from RRC
SAP/protocol.

11) New function in CPHY SAP for delivering SIB1 from PHY to RRC.

Note that I don't find 3GPP mentioning the use of layer 1 filtering during cell
selection period. But I still find it important to use at least some averaging
here, so that the cell selection procedure is not vulnerable to channel fading.

Also note that point #6 is not something based on 3GPP. Since I can't find a
specification for it (yet), so I decide to make up a simple procedure by myself.

Thanks for reading. I've asked so many reviews and feedback from you guys, I
hope it's not too bothersome. It's just that I'm still learning in PHY-related
stuff, so I guess it's a better if I figure out any mistake earlier, before I've
gone too far with wrong assumptions.

Regards,

-budi-

[Nicola Baldo, 2013-07-19 23:37:14]

Hi Budi, 

thanks for the detailed description, your effort in re-designing the cell
selection part is very much appreciated. 
However, my general impression is that you are moving to the PHY some
functionality that actually belongs to the RRC. Please see my comments inline
below.

On 2013/07/16 08:23:21, buherman wrote:
> 
> --- UE PHY ---
> 
> 1) Starts by attaching itself to the channel, listening to 6 RBs for PSS, but
> not synchronized to any particular cell. Thus PSS is the only signal it can
> listen to.

sounds good

> 
> 2) Has 3 states: CELL_SEARCH, DECODING_BCH, and ATTACHED.

I'd just have two states, CELL_SEARCH and SYNCHRONIZED.
See below for why 2 and not 3.
I'd avoid the term ATTACHED since it could create some confusion with the
attachment procedure - the UE could be attached via one cell but still be
temporarily synced with another e.g. for UE measurements with purpose reportCGI
(which we won't implement, but that's not the point).

> 
> 3) Starting from CELL_SEARCH, UE collects the PSS and use them on UE
> measurements' layer 1 filtering, so an averaged set of RSRP will be produced
> after every 200 ms. At this point, UE will choose the strongest one,
synchronize
> to it, and switch to DECODING_BCH state.

ok that "the UE will choose the strongest one", but this will be done by the UE
RRC, not the UE PHY. The PHY just reports to the RRC all the detected PHY cell
IDs and their strength. 

> 
> 4) In DECODING_BCH state, UE will start to receive MIB and SIB1 from a
> particular cell. These two messages are simply relayed to RRC.

ok but for the SYNCHRONIZED state.


> 
> --- UE RRC ---
> 
> 5) When RRC has received both MIB and SIB1 from a cell and its state is still
> IDLE_CELL_SELECTION, it starts the initial cell selection procedure.

as I said a few lines above, I don't agree with this. Instead, the RRC will
receive the list of physical cell IDs from the PHY together with their
associated strength, and then the RRC will select the strongest one and tell the
PHY to synchronize to it. I though I already described this in an earlier
email...


> 
> 6) When it fails (e.g. because of incompatible PLMN/CSG), RRC tells PHY to
retry
> the cell search. This is done by a new function RetryCellSearch in CPHY SAP.
PHY
> will switch back to CELL_SEARCH state and retry the cell search procedure
(point
> #3 above) while avoiding the previous cell (there's an std::set in PHY to keep
> track which cells have been tried).

sorry but I disagree again. This functionality is part of the RRC state machine,
and is clearly described in 36.304. The cell re-selection should not be done by
the PHY.


> 
> 7) If successful, RRC tells PHY to switch to ATTACHED state (by calling the
new
> function Attach in CPHY SAP) and RRC camps to that cell (RRC state switches to
> IDLE_CAMPED_NORMALLY).

of course I would call the new state SYNCHRONIZED. 
Can't you just reuse the existing CPHY SAP method SyncronizeWithEnb()?


> 
> 8) There's a limit of how many retries can be done, and I put it as an
attribute
> of UE RRC. If the limit is exceeded, RRC simply stops calling RetryCellSearch,
> so it will stay in IDLE_CELL_SELECTION for the rest of the simulation (unless
> someone calls LteHelper::Attach on it).

this would be an additional feature :-)
though I wonder if the retry limit is realistic... do our phones really ever
give up idle cell selection?

> 
> --- MIB and SIB1 ---
> 
> 9) New LTE control message for SIB1, which will be sent periodically by eNodeB
> PHY.
> 
> 10) Removed all functions for sending and receiving MIB and SIB1 from RRC
> SAP/protocol.
> 
> 11) New function in CPHY SAP for delivering SIB1 from PHY to RRC.

I think the above are ok according to what we had agreed in our previous
discussion, at least if I remember correctly ;-)


> 
> Note that I don't find 3GPP mentioning the use of layer 1 filtering during
cell
> selection period. But I still find it important to use at least some averaging
> here, so that the cell selection procedure is not vulnerable to channel
fading.

I think 3GPP leaves layer 1 filtering as vendor/product specific, so I guess
your approach is fine.

> 
> Also note that point #6 is not something based on 3GPP. Since I can't find a
> specification for it (yet), so I decide to make up a simple procedure by
myself.

your initiative is appreciated :-) but in this case I'd prefer to stick with
3GPP as per my comment above.

> 
> Thanks for reading. I've asked so many reviews and feedback from you guys, I
> hope it's not too bothersome. It's just that I'm still learning in PHY-related
> stuff, so I guess it's a better if I figure out any mistake earlier, before
I've
> gone too far with wrong assumptions.

No problem from my side, and sorry for the late reply! 


Kind regards,

Nicola

[buherman, 2013-07-21 20:22:43]

Hi Nicola,

Thanks, please find my comments below.

On 2013/07/19 23:37:14, Nicola Baldo wrote:
> Hi Budi, 
> 
> thanks for the detailed description, your effort in re-designing the cell
> selection part is very much appreciated. 
> However, my general impression is that you are moving to the PHY some
> functionality that actually belongs to the RRC. Please see my comments inline
> below.

Indeed. I'm having trouble finding exact statements from 3GPP and books about
whether this procedure belongs to RRC or PHY. So I made my own guess on this
issue.

I will move them from PHY to RRC. I suppose this wouldn't be too difficult, and
there should be no change in the end results. I'll try to finish this before the
mid-term code review.

> > --- UE PHY ---
> > 
> > 1) Starts by attaching itself to the channel, listening to 6 RBs for PSS,
but
> > not synchronized to any particular cell. Thus PSS is the only signal it can
> > listen to.
> 
> sounds good

But currently this starts right away by default. According to our last meeting,
we'd like to have a new LteHelper::Attach function, but without the eNodeB
argument, to trigger the initial cell selection. I forgot about this when I
wrote the code, but I will add this.

> > 2) Has 3 states: CELL_SEARCH, DECODING_BCH, and ATTACHED.
> 
> I'd just have two states, CELL_SEARCH and SYNCHRONIZED.
> See below for why 2 and not 3.
> I'd avoid the term ATTACHED since it could create some confusion with the
> attachment procedure - the UE could be attached via one cell but still be
> temporarily synced with another e.g. for UE measurements with purpose
reportCGI
> (which we won't implement, but that's not the point).

I wasn't aware of that requirement for reportCGI. I'll update the code to use 2
states as you suggested.

> > 3) Starting from CELL_SEARCH, UE collects the PSS and use them on UE
> > measurements' layer 1 filtering, so an averaged set of RSRP will be produced
> > after every 200 ms. At this point, UE will choose the strongest one,
> synchronize
> > to it, and switch to DECODING_BCH state.
> 
> ok that "the UE will choose the strongest one", but this will be done by the
UE
> RRC, not the UE PHY. The PHY just reports to the RRC all the detected PHY cell
> IDs and their strength. 

Okay, I can fix this.

> > 4) In DECODING_BCH state, UE will start to receive MIB and SIB1 from a
> > particular cell. These two messages are simply relayed to RRC.
> 
> ok but for the SYNCHRONIZED state.
> 
> 
> > 
> > --- UE RRC ---
> > 
> > 5) When RRC has received both MIB and SIB1 from a cell and its state is
still
> > IDLE_CELL_SELECTION, it starts the initial cell selection procedure.
> 
> as I said a few lines above, I don't agree with this. Instead, the RRC will
> receive the list of physical cell IDs from the PHY together with their
> associated strength, and then the RRC will select the strongest one and tell
the
> PHY to synchronize to it. I though I already described this in an earlier
> email...

I don't see the problem with this bullet point. Let me clarify the procedure
first from the beginning of simulation:
1) PHY listens to PSS and averages the RSRP
2) After 200 ms, PHY gives RRC a list of cell ID and RSRP of all detected cells
3) RRC chooses the cell with the biggest RSRP and tells PHY to synchronize to
that cell
4) 5 milliseconds after that, PHY provides RRC with SIB1 from that cell
5) Another 5 milliseconds after that, PHY provides RRC with MIB from that cell

If I understand correctly, only after this point the RRC can start the initial
cell selection procedure. That's why I put the receiving of MIB and SIB1 as the
trigger to initial cell selection.

> > 6) When it fails (e.g. because of incompatible PLMN/CSG), RRC tells PHY to
> retry
> > the cell search. This is done by a new function RetryCellSearch in CPHY SAP.
> PHY
> > will switch back to CELL_SEARCH state and retry the cell search procedure
> (point
> > #3 above) while avoiding the previous cell (there's an std::set in PHY to
keep
> > track which cells have been tried).
> 
> sorry but I disagree again. This functionality is part of the RRC state
machine,
> and is clearly described in 36.304. The cell re-selection should not be done
by
> the PHY.

I don't mean this as cell reselection. This is a part of cell selection, which
is the part where UE tries to find suitable cell.

In the case of PLMN or CSG doesn't match, the cell doesn't qualify as a suitable
cell, but qualifies as an acceptable cell. 3GPP says that if suitable cell
cannot be found, UE should attempt to connect to an acceptable cell. But they
don't specify in exact how long the UE should keep trying until it gives up
finding suitable cell. In my approach, "no suitable cell found" means "after
confirming that 4 strongest surrounding cells are not suitable cell".

3GPP also says that UE is only required to check one strongest cell, but I'm not
sure if this relates to the attempt of finding suitable cell.

> > 7) If successful, RRC tells PHY to switch to ATTACHED state (by calling the
> new
> > function Attach in CPHY SAP) and RRC camps to that cell (RRC state switches
to
> > IDLE_CAMPED_NORMALLY).
> 
> of course I would call the new state SYNCHRONIZED. 
> Can't you just reuse the existing CPHY SAP method SyncronizeWithEnb()?

I'm already reusing SyncronizeWithEnb for DECODING_BCH state. When later I get
rid of the ATTACHED state, I will also remove the Attach CPHY SAP function.

> > 8) There's a limit of how many retries can be done, and I put it as an
> attribute
> > of UE RRC. If the limit is exceeded, RRC simply stops calling
RetryCellSearch,
> > so it will stay in IDLE_CELL_SELECTION for the rest of the simulation
(unless
> > someone calls LteHelper::Attach on it).
> 
> this would be an additional feature :-)
> though I wonder if the retry limit is realistic... do our phones really ever
> give up idle cell selection?

As I mentioned above, the retry mechanism is meant as an interpretation of "no
suitable cell is found", which then switches the UE state to ANY_CELL_SELECTION
mode. In real case, after this UE would camp to an acceptable cell and receive
limited service. But I don't plan to develop this behaviour, so instead I
substituted it with a "give up" behaviour.

But now after thinking again for a while, I sense that this retry limit doesn't
have a clear purpose. There's no need for UE to stop finding suitable cell,
because there's no concept of camping to acceptable cell in the simulation.

Therefore I'll revise this procedure and make UE retry indefinitely.

> > --- MIB and SIB1 ---
> > 
> > 9) New LTE control message for SIB1, which will be sent periodically by
eNodeB
> > PHY.
> > 
> > 10) Removed all functions for sending and receiving MIB and SIB1 from RRC
> > SAP/protocol.
> > 
> > 11) New function in CPHY SAP for delivering SIB1 from PHY to RRC.
> 
> I think the above are ok according to what we had agreed in our previous
> discussion, at least if I remember correctly ;-)
> 
> 
> > 
> > Note that I don't find 3GPP mentioning the use of layer 1 filtering during
> cell
> > selection period. But I still find it important to use at least some
averaging
> > here, so that the cell selection procedure is not vulnerable to channel
> fading.
> 
> I think 3GPP leaves layer 1 filtering as vendor/product specific, so I guess
> your approach is fine.
> 
> > 
> > Also note that point #6 is not something based on 3GPP. Since I can't find a
> > specification for it (yet), so I decide to make up a simple procedure by
> myself.
> 
> your initiative is appreciated :-) but in this case I'd prefer to stick with
> 3GPP as per my comment above.
> 
> > 
> > Thanks for reading. I've asked so many reviews and feedback from you guys, I
> > hope it's not too bothersome. It's just that I'm still learning in
PHY-related
> > stuff, so I guess it's a better if I figure out any mistake earlier, before
> I've
> > gone too far with wrong assumptions.
> 
> No problem from my side, and sorry for the late reply! 
> 
> 
> Kind regards,
> 
> Nicola

[Nicola Baldo, 2013-07-25 13:22:14]

Hi Budi,

I think we are converging on most points, please find below my comments
on the open issues.


> > > --- UE RRC ---
> > > 
> > > 5) When RRC has received both MIB and SIB1 from a cell and its state is
> still
> > > IDLE_CELL_SELECTION, it starts the initial cell selection procedure.
> > 
> > as I said a few lines above, I don't agree with this. Instead, the RRC will
> > receive the list of physical cell IDs from the PHY together with their
> > associated strength, and then the RRC will select the strongest one and tell
> the
> > PHY to synchronize to it. I though I already described this in an earlier
> > email...
> 
> I don't see the problem with this bullet point. Let me clarify the procedure
> first from the beginning of simulation:
> 1) PHY listens to PSS and averages the RSRP
> 2) After 200 ms, PHY gives RRC a list of cell ID and RSRP of all detected
cells
> 3) RRC chooses the cell with the biggest RSRP and tells PHY to synchronize to
> that cell
> 4) 5 milliseconds after that, PHY provides RRC with SIB1 from that cell
> 5) Another 5 milliseconds after that, PHY provides RRC with MIB from that cell
> 
> If I understand correctly, only after this point the RRC can start the initial
> cell selection procedure. That's why I put the receiving of MIB and SIB1 as
the
> trigger to initial cell selection.

maybe it's just a misunderstanding about the naming. My point is that, according
to the description in TS 36.304 section 5.2.3.1 a),  "initial cell selections"
is a procedure that includes the step that you mentioned. It's not a separate
step done afterwards.

Apart from the naming, the procedure that you described looks ok to me. 
To be clear, I think the steps that you mentioned would conclude with the
following additional steps:

6) the RRC reads the PLMN from the SIB1
7) if PLMN matches, the cell id on which the PHY is already synchronized
is confirmed as a suitable cell, hence the RRC considers itself camped
on this cell (switches to CAMPED_NORMALLY) and the initial cell
selection phase ends
8) if PLMN does not match, in principle the RRC should try other
frequencies. But I wouldn't do this for now. About trying other cells at the
same frequency, I am not sure, see the next comment.



 
> > > 6) When it fails (e.g. because of incompatible PLMN/CSG), RRC tells PHY to
> > retry
> > > the cell search. This is done by a new function RetryCellSearch in CPHY
SAP.
> > PHY
> > > will switch back to CELL_SEARCH state and retry the cell search procedure
> > (point
> > > #3 above) while avoiding the previous cell (there's an std::set in PHY to
> keep
> > > track which cells have been tried).
> > 
> > sorry but I disagree again. This functionality is part of the RRC state
> machine,
> > and is clearly described in 36.304. The cell re-selection should not be done
> by
> > the PHY.
> 
> I don't mean this as cell reselection. This is a part of cell selection, which
> is the part where UE tries to find suitable cell.
> 
> In the case of PLMN or CSG doesn't match, the cell doesn't qualify as a
suitable
> cell, but qualifies as an acceptable cell. 3GPP says that if suitable cell
> cannot be found, UE should attempt to connect to an acceptable cell. But they
> don't specify in exact how long the UE should keep trying until it gives up
> finding suitable cell. In my approach, "no suitable cell found" means "after
> confirming that 4 strongest surrounding cells are not suitable cell".
> 
> 3GPP also says that UE is only required to check one strongest cell, but I'm
not
> sure if this relates to the attempt of finding suitable cell.
> 

In a previous comment, Jaime wrote that "the system information is
common to all cells". I think it makes sense that all cells at a
frequency have the same PLMN, because each frequency is licensed to a
single operator. If this is confirmed (any 3GPP reference?) it is sufficient to
get the MIB and the SIB1 of the strongest cell to get the system information for
that frequency.


Regards,

Nicola

[buherman, 2013-07-26 11:45:57]

Hi Nicola,

Thanks for your comments. I think we're almost there. Just one more issue still
lingering here. Please see below.

-budi-


On 2013/07/25 13:22:14, Nicola Baldo wrote:
> Hi Budi,
> 
> I think we are converging on most points, please find below my comments
> on the open issues.
> 
> 
> > > > --- UE RRC ---
> > > > 
> > > > 5) When RRC has received both MIB and SIB1 from a cell and its state is
> > still
> > > > IDLE_CELL_SELECTION, it starts the initial cell selection procedure.
> > > 
> > > as I said a few lines above, I don't agree with this. Instead, the RRC
will
> > > receive the list of physical cell IDs from the PHY together with their
> > > associated strength, and then the RRC will select the strongest one and
tell
> > the
> > > PHY to synchronize to it. I though I already described this in an earlier
> > > email...
> > 
> > I don't see the problem with this bullet point. Let me clarify the procedure
> > first from the beginning of simulation:
> > 1) PHY listens to PSS and averages the RSRP
> > 2) After 200 ms, PHY gives RRC a list of cell ID and RSRP of all detected
> cells
> > 3) RRC chooses the cell with the biggest RSRP and tells PHY to synchronize
to
> > that cell
> > 4) 5 milliseconds after that, PHY provides RRC with SIB1 from that cell
> > 5) Another 5 milliseconds after that, PHY provides RRC with MIB from that
cell
> > 
> > If I understand correctly, only after this point the RRC can start the
initial
> > cell selection procedure. That's why I put the receiving of MIB and SIB1 as
> the
> > trigger to initial cell selection.
> 
> maybe it's just a misunderstanding about the naming. My point is that,
according
> to the description in TS 36.304 section 5.2.3.1 a),  "initial cell selections"
> is a procedure that includes the step that you mentioned. It's not a separate
> step done afterwards.
> 
> Apart from the naming, the procedure that you described looks ok to me. 
> To be clear, I think the steps that you mentioned would conclude with the
> following additional steps:
> 
> 6) the RRC reads the PLMN from the SIB1
> 7) if PLMN matches, the cell id on which the PHY is already synchronized
> is confirmed as a suitable cell, hence the RRC considers itself camped
> on this cell (switches to CAMPED_NORMALLY) and the initial cell
> selection phase ends
> 8) if PLMN does not match, in principle the RRC should try other
> frequencies. But I wouldn't do this for now. About trying other cells at the
> same frequency, I am not sure, see the next comment.

I see. Then I think it would be better if I rename the function
InitialCellSelection() in RRC to something like EvaluateCellForSelection(). And
I think I can also keep the name CellSearch() in PHY, because if I understand
correctly this term is used to describe the related procedure in PHY.

I've completed the documentation on initial cell selection (but still in my
local repo). So I will try to re-arrange the structure to fit these new
definitions.

> In a previous comment, Jaime wrote that "the system information is
> common to all cells". I think it makes sense that all cells at a
> frequency have the same PLMN, because each frequency is licensed to a
> single operator. If this is confirmed (any 3GPP reference?) it is sufficient
to
> get the MIB and the SIB1 of the strongest cell to get the system information
for
> that frequency.

This is the last part I'm still puzzled with. I also have the same
understanding: one PLMN occupies one frequency. But I don't want to go that far,
since right now we've always assumed intra-frequency. So in terms of PLMN ID, I
think we can safely assume that SIB1 from any cells of the same frequency would
have the same PLMN ID.

But let's shift the discussion to CSG. I read that operator may choose to share
the same frequencies for Macro and HeNB (they call it time partitioning in
Section 5.1 of 3GPP 36.922). That means Macro and HeNB transmit different CSG ID
in their respective SIB1.

Taking lena-dual-stripe as an example, CMIIW, there can be a situation where a
macro UE is positioned inside an apartment, so it receives better signal from a
HeNB than from a Macro cell. That means when the macro UE perform cell search,
the HeNB will be the strongest in the frequency. After synchronizing and
received the SIB1, it will find out that it can't access the cell because of
CSG.

There's no other frequency for the UE to check, so I can let the UE to give up
at this point. But then lena-dual-stripe will be broken if I change it to use
initial cell selection (whenever there's a macro UE which is too close to a
HeNB). So I propose to let UE retry the same frequency for unlimited number of
times. Hopefully in the second try UE will get the Macro cell and then attach to
it.

This is probably not in good terms with 3GPP, but I think it's a not-so-bad
middle approach, given that I'm trying to avoid developing too many features
(e.g. multiple frequency, any cell selection, camping to acceptable cells,
limited service, emergency calls, etc.).

PS. Back to PLMN, frankly I can't see any clear benefit from implementing this
feature. Not so sure anymore why I wanted to implement it in the first place.
Well, it was very easy to develop it together with CSG, but maybe it doesn't
make sense to use it in simulation until we have support for multiple frequency.
What do you think, should I keep it here for future use, or just delete it?

[nbaldo_cttc.es, 2013-07-26 15:08:52]

Hi Budi,

On 07/26/2013 01:45 PM, budiarto.herman@magister.fi wrote:
>> 6) the RRC reads the PLMN from the SIB1
>> 7) if PLMN matches, the cell id on which the PHY is already
> synchronized
>> is confirmed as a suitable cell, hence the RRC considers itself camped
>> on this cell (switches to CAMPED_NORMALLY) and the initial cell
>> selection phase ends
>> 8) if PLMN does not match, in principle the RRC should try other
>> frequencies. But I wouldn't do this for now. About trying other cells
> at the
>> same frequency, I am not sure, see the next comment.
> 
> I see. Then I think it would be better if I rename the function
> InitialCellSelection() in RRC to something like
> EvaluateCellForSelection(). 

Yes that could be fine. Maybe "Cells"


> And I think I can also keep the name
> CellSearch() in PHY, because if I understand correctly this term is used
> to describe the related procedure in PHY.

Yess I agree that "cell search" is the name of the PHY procedure.

> 
> I've completed the documentation on initial cell selection (but still in
> my local repo). So I will try to re-arrange the structure to fit these
> new definitions.
> 
>> In a previous comment, Jaime wrote that "the system information is
>> common to all cells". I think it makes sense that all cells at a
>> frequency have the same PLMN, because each frequency is licensed to a
>> single operator. If this is confirmed (any 3GPP reference?) it is
> sufficient to
>> get the MIB and the SIB1 of the strongest cell to get the system
> information for
>> that frequency.
> 
> This is the last part I'm still puzzled with. I also have the same
> understanding: one PLMN occupies one frequency. But I don't want to go
> that far, since right now we've always assumed intra-frequency. So in
> terms of PLMN ID, I think we can safely assume that SIB1 from any cells
> of the same frequency would have the same PLMN ID.

ok

> But let's shift the discussion to CSG. I read that operator may choose
> to share the same frequencies for Macro and HeNB (they call it time
> partitioning in Section 5.1 of 3GPP 36.922). That means Macro and HeNB
> transmit different CSG ID in their respective SIB1.

yes, co-channel femtocell deployment is indeed a practical scenario that
should be considered.

> 
> Taking lena-dual-stripe as an example, CMIIW, there can be a situation
> where a macro UE is positioned inside an apartment, so it receives
> better signal from a HeNB than from a Macro cell. That means when the
> macro UE perform cell search, the HeNB will be the strongest in the
> frequency. After synchronizing and received the SIB1, it will find out
> that it can't access the cell because of CSG.

I agree, with the currently described implementation we would have a
problem.


> There's no other frequency for the UE to check, so I can let the UE to
> give up at this point. But then lena-dual-stripe will be broken if I
> change it to use initial cell selection (whenever there's a macro UE
> which is too close to a HeNB). 
> So I propose to let UE retry the same
> frequency for unlimited number of times. Hopefully in the second try UE
> will get the Macro cell and then attach to it.

I think just blindly retrying won't work well. Quite often users will
run scenarios with static nodes and no fading, so the strongest cell
will stay strongest forever, and the macro UE will never camp on the cell.

According to 36.304 section 4.3, for a macro UE, a GSC HeNB is not
suitable. Hence, for a co-channel deployment to work, I don't see how
this could work for a UE that only considers the strongest cell, which
is the minimum requirement as per section 5.2.3.1

So what? Maybe we could have EvaluateCellsForSelection() exclude cells
that are detected to be CSG, so when the selection is reattempted, it
will finally select the macro. What do you think?

> 
> This is probably not in good terms with 3GPP, but I think it's a
> not-so-bad middle approach, given that I'm trying to avoid developing
> too many features (e.g. multiple frequency, any cell selection, camping
> to acceptable cells, limited service, emergency calls, etc.).
> 
> PS. Back to PLMN, frankly I can't see any clear benefit from
> implementing this feature. Not so sure anymore why I wanted to implement
> it in the first place. Well, it was very easy to develop it together
> with CSG, but maybe it doesn't make sense to use it in simulation until
> we have support for multiple frequency. What do you think, should I keep
> it here for future use, or just delete it?

Well, at first PLMN seemed appealing and easy to do, but after all these
discussions, I agree that having it makes little sense, at least until
we have also multi-frequency scanning.

Anyway, it doesn't hurt to have the PLMN in system information, so I
would leave it there.

Regards,

Nicola

[buherman, 2013-07-29 06:32:41]

Hi Nicola,

Thanks. I have a few comments below.

-budi-

On 2013/07/26 15:08:52, nbaldo_cttc.es wrote:
> > I see. Then I think it would be better if I rename the function
> > InitialCellSelection() in RRC to something like
> > EvaluateCellForSelection(). 
> 
> Yes that could be fine. Maybe "Cells"

Um.. but the function would only evaluate one cell, that is the cell the SIB1 is
received from.

I'm updating the documentation again, and I'll send it to you when I'm done.

> I think just blindly retrying won't work well. Quite often users will
> run scenarios with static nodes and no fading, so the strongest cell
> will stay strongest forever, and the macro UE will never camp on the cell.

Yes, therefore I mark this cell as "acceptable" by saving its cell ID to
m_acceptableCell. In the next turns, the UE won't attempt to synchronize to
cells listed in m_acceptableCell. This should prevent UE from retrying to the
same cell again and again.

> Well, at first PLMN seemed appealing and easy to do, but after all these
> discussions, I agree that having it makes little sense, at least until
> we have also multi-frequency scanning.
> 
> Anyway, it doesn't hurt to have the PLMN in system information, so I
> would leave it there.

Alright, I'll remove PLMN as cell selection criteria, and also remove the helper
function for setting PLMN ID on UE and eNodeB.