囧，LTE的PCCH和BCCH在MAC层怎么打包啊？

BCCH和PCCH不算SRB和DRB，没有LCID。
MAC PDU那一章注明了是DL-SCH UL-SCH，明摆着排除了PCCH/PCH。
BCCH算是DL-SCH家的。但是LCID就没它的份。
如果PCCH和BCCH用transparent MAC PDU，基站如何告诉UE，MAC SDU的长度呢（反言之，就是padding有多少）？我只能猜到，UE按照36.331规定的各种SIB块与Paging消息的长度，解出MAC PDU中的消息，剩余的就是padding。

不用告诉UE消息长度吧，这些消息用asn.1编码的，里面指示了长度，剩下的就是padding， mac层不用加任何头。

我记得是透传，不需要任何的segment或者packing。

确实是透传，物理层过了CRC之后，数据送到MAC层，并且告诉MAC层是BCCH，或者PCCH的数据，MAC层直接把数据打包发到RRC，告诉RRC是BCH或者PCH的数据，就可以了。整个L2（MAC,RLC,PDCP）不对数据做任何处理。

透传

我觉得2楼说得有理。我原来也猜是那么着，不过不懂ASN.1啊。
如果说MAC完全不管似乎也不完全准确吧，对于SIB和Paging，MAC要打padding到某个TB的。协议里有transparent MAC PDU，但是木有说用来干啥，我猜是为BCCH和PCCH准备的。
另外，PDCP应该是要做cipering吧？

嗯，当MAC所分的TBsize大于BCCH、PCCH的消息长度时，大于的部分就作为padding。
BCCH、PCCH、CCCH的消息在RLC用TM模式透传到RRC层，不经过PDCP层的加密，他们没有PDCP的SN。

所有L3信令应该都是没有加密的，只有数据业务可以加密。

SRB上传的DCCH信令可以加密，CCCH信令不过PDCP层，不能加密。

CCCH会经过RLC 用TM模式到RRC
BCCH 和PCCH是不经过RLC的吧，直接MAC层就到RRC了。
因为BCCH和PCCH是透明的MAC pdu，CCCH的MAC PDU还是正常的MAC pdu，mac层对于CCCH的LCID固定是00000的。

嗯，CCCH是要加MAC子头的。对BCCH和PCCH，RLC协议中的TM实体里面写的是有包含这些消息的，但由于RLC透传时不做任何处理，实际实现时也可以从MAC直接到RRC。

透传