极好的LTE RACH 过程以及随机接入详解.doc

设备故障修复时什么最难？我的经验是“若问题是在进行过程中出现的，那么寻找原因并修复相对来说比较容易(也许比起我这样动嘴皮子还是要难一点)；而如果是在开始时就出的问题，那才让人头疼。”比如说，你在网络模拟器处，为一个UE的接入设好了所有参数，然后你打开了这个UE。几秒钟后，UE开始启动，几秒钟后你看到UE屏幕上方的小天线图标……然后再过几秒钟，你看到屏幕上显示”SOS”或“无服务”，而不是本应显示的运营商名及标识信号正常的天线图标。上面说的就是指“在进行过程中出现的问题”。在这种情况下，只要你查查UE和设备的log，你就至少能准备地定位到问题出现的地方，并从那里入手深入分析原因。但是，如若你遭遇了这样的事情呢？你设好网络模拟器的所有参数然后打开UE，UE启动，显示“搜索网络”，然后就挂在这了。没有信号格图标，甚至也没有”SOS”，只是显示“无服务”。查看UE和网络模拟器的log，发现没有信令消息。这种情况才让人头疼。 举例来说， ⑴ 你打开WCDMA UE，却看不到”RRC Connection Request”时怎么办？ ⑵ 你打开GSM UE，却看不到”Channel Request”时怎么办？ ⑶ 你打开LTE UE，却看不到”RACH Preamble”时怎么办？ 你需要做的第一件事是，理解这个过程的所有细节，理解高层信令和物理层的处理方式。你还需要利用合适的，能显示这些过程细节的设备。如果你的设备无法记录log信息或是只能记录高层信令log，那么故障排解依然会非常困难。若你已有了合适的设备，接下来要做的就是理解这些过程的细节知识。没有知识，再好的设备也毫无用处。所以呢，马上进入的是LTE的第一个信令过程：随机接入。(可能有人会说其实RACH之前还有其它步骤，如频率同步，时间同步，MIB/SIB解码等，不过这些过程更多的是基带处理，所以我跳过了。) RACH过程是什么时候发生？ 在协议中(36.300 10.1.5)，RACH过程在这些时候发生： ⑴ 以RRC_IDLE状态作为起始的初始接入； ⑵ RRC连接重建立过程； ⑶ 切换； ⑷ RRC_CONNECTED状态下，下行数据到达，需要启动随机接入的； 如 当上行同步状态为“失步”时； ⑸ RRC_CONNECTED状态下，上行数据到达，需要启动随机接入的； 如 当上行同步状态为“失步”时，或没有可承载SR消息的PUCCH资源时； ⑹ RRC_CONNECTED状态下，进行定位，需要启动随机接入的； 如 为UE定位需要获取当前时间提前(TA)时； Scell上进行的随机接入过程，还可用来为相应的TA组进行时间对齐。 两类RACH过程：竞争与非竞争 当UE发送PRACH preamble时，它用特定的标识来发。每个LTE小区中都有64个不同的标识，UE每次接入时随机地从中选择一个。 这是否意味着可能同时有多个UE发送相同的标识？是的。 这种可能性完全存在。其含义是不同UE所发的相同的PRACH preamble同时到达网络侧。这种PRACH冲突的情形称作“竞争”，允许这种竞争存在的RACH过程称作“基于竞争的”RACH过程。在基于竞争的PACH过程中，网络通过后续的附加过程来解决冲突问题，这个附加过程叫做“竞争解决”步骤。 而在某些情况下，出于某种原因(如时延限制)这种竞争是不能被容忍，必须避免的。通常在这种情况下，网络提前告诉每个UE何时，用哪个preamble来发起随机接入。当然，这种情况下，网络所分配的preamble是不会产生冲突的。这种RACH过程叫作“无竞争的”RACH过程。进行无竞争RACH的UE，在RACH前应已处于连接态，如切换场景。 典型的基于竞争的RACH流程如下： i) UE -- NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size) ii) UE -- NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message) iii) UE -- NW : L2/L3 message iv) Message for early contention resolution 当第一步发生了竞争冲突时，如两个UE同时发PRACH时，它们会在第二步收到相同的T_C-RNTI及分配的资源。然后，在第三步中两个UE在同一个分配的资源内(时/频位置)发L2/L3消息。两个UE在同样的时频资源处发相同信息会导致什么后果？一种可能是这两个信号彼此干扰，网络都无法解出。这种情况下，所有UE都不会收到网络下发的回复(HARQ ACK)，它们会认为本次RACH失败，回到第一步重新发起RACH过程。另一种