Serving RNC是否也可以是CRNC？

Serving RNC当然可以是Control RNC！楼主需要把RNC的各种概念弄清楚：

SRNC主要针对在跨RNC的情况下，两个RNC通过Iur相连，其中与核心网（通过Iu口）保持连接的为SRNC，另外一个未Drift RNC（DRNC）。

而Control RNC则是控制主小区所在NodeB对应的RNC。

因此当软切换时，主小区如果在SRNC下，这个时候SRNC即为CRNC；
如果主小区在DRNC下，则此时DRNC为CRNC。

（１）CRNC之所以说是对NodeB而言是因为CRNC主要负责公共物理信道、传输信道等资源的分配。
（２）SRNC负责专用信道（物理、传输）的资源分配所以可以理解为针对UE的
简单一点理解就是，SRNC=Serving
RNC用于处理Uu接口连接，分配平衡各个专用无线资源这样一个RNC。CRNC，用于控制其下的Node
B，分配建立传输资源，处理各节点同步的RNC。SRNC肯定是CRNC，但CRNC未必是SRNC。
NodeB通信上下文和CRNC通信上下文是UE在NodeB和RNC侧的资源映射，两个的资源配置应该报持一致。CRNC通信上下文有CRNC在发送无线链路建立时创建，NODEB在接收到无线链路建立请求消息时创建一个NodeB的通信上下，并在无线链路建立响应消息中将NodeB通信上下文ID告知CRNC。可以看到，在所有的专用NBAP过程中，下行的NBAP消息所包含的都是NodeB通信上下文标识，只有在无线链路建立请求消息中包含的是CRNC通信上下文标识。这也可以解释为什么无线链路是公共过程，因为CRNC在发起无线链路建立过程时，对应的上下文在NodeB并不存在，所以该过程并不针对某个NodeB通信上下文，是公共过程。NodeB通信上下文和CRNC通信上下包含的逻辑资源包括无线链路信息、DCH信息、专用测量信息和MAC-D Flow信息。
目前在NSN的RNC中，CRNTI和SRNTI一致
希望对你有用。

可以，Serving RNC可以是Control RNC

可以的，只是相对的对象不一样