what are possible reasons for SFN and SF missmatch of LTE Layer-1 and Layer-2 at eNedeB?

Question

Auto-Configuration of Board Not Possible Subrack=1,Slot=2 (Alarm Cause: Auto-install for PiuType failed, reasonThe FTP server to be used for downloads of load modules is not accessible.? Alarm observed at Ericsson DUS41 while making IDL2 configuration.

Answer 1

Hi sripathi,

The main reason is If MAC and scheduler took more than 1ms time to process the Subframe messages then L1 and L2 will face SFN_SF mismatch.

In LTE there are two master one is PHY master and another one is MAC master. If PHY is master means what ever PHY gives SFN_SF MAC should use the same to process subframe messages. If MAC is master, PHY will have initially one SFN_SF at synch time, if mac wanted to change that SFN_SF then MAC can change. So meanwhile of this processing both will have different SFN_SF.

Comments

Thanks for your answer jaganathan, here am getting subframe indication from PHY and mac using it. with multi UE after 10 hours of successful run this SFN_SF mismatch happening .... Can you please suggest how to resolve it.

---

Hi,
 
There can be two reason, In some case may be your MAC is taking more than 1ms , you can keep gettime and end time to check MAC timing while mismatch happening. This you can avoid by optimizing.

second reason is you may not get the proper SF indication with 1ms gape.Every 1ms Phy has to give SF indication, If because of some load PHY is not giving SF indication means then this can happen.(we faced PHY SF indication problem).This you have to check with L1 team.

If MAC is master in you case just send what ever SFNSF you have PHY will accept by sending Error code.

---

Hi jaganathan, As i seen in logs expected SFN_SF is always leading than received SFN_SF. Hence PHY not providing subframe indication in every ms. As per your knowledge, what are reasons for high load on phy. can you please share?

---

Hi,

With this assumption you cant say PHY is delaying,Because assume SFn_SF is 923,4 If MAC took delay and sent it after 1.5 ms (at this time PHY subframe already reached 923,5 because of MAC delay), then in next sub frame PHY expected SFN_SF is 923,6 but you will process 923,5 then PHY will say expected SFn_SF is 923,6 and yours is 923,5.
If you still suspect your PHY problem , then High load is come when you have more UE per TTI , try to reduce UE per TTI then you can see the difference. But most of the PHY wont make problem because it is designed such a way that it will not miss any TTI. even if it has more load then he will return that message by error code saying which actually makes him load. never suspect because of PHY load it missed untill unless you are developing PHY. If you are working on PHY then how ever you knows which makes more load.

Hope you understand :) let me know if you have any question .