当然可以。PDCCH传输的是调度控制信息，对于TDD，当然不可以在同一个子帧传输上下行数据了，资源肯定是分开调度了，但DCI可以同时存在不同格式。

小弟还有一个疑问。在PDCCH盲检的时候，假如用户检测出了1个DCI，是不是还不能停止盲检？ 如果说某一个下行子帧上该用户只有一个DCI，那用户检测出一个DCI以后仍然继续检测岂不是做了很多无用功？ 难道用户事先知道有几个DCI的到来？

这就是所谓的搜索空间的作用了，用户只能在公共搜索空间和专用的搜索空间搜索，搜索一个XRNTI加扰的信息所需要进行搜索的最大次数是44次，很多书中都有描述，当然如果UE需要几个X-RNTI加扰的PDCCH，可能搜索的次数可能大于44次。

是吗？ 但是搜索DCI0的时候也是用C-RNTI加扰的，比如某个下行子帧用C-RNTI加扰，那UE还是不知道此时它有多少个DCI，那问题还是没有解决啊。
个人觉得X-RNTI只是在不同的场景的应用，比如寻呼，接入，半静态调度等等，所以我觉得同一个时间只会有一个RNTI。

C-RNTI只会有一个，上下行的DCI都使用它来加扰（这里就不考虑使用SI-RNTI/RA-RNTI的加扰）。

UE在盲检时，知道当前处于什么状态，期待接收到什么样的DCI。比如说，如果UE有上行数据要发，它在发完SR（也可能是随机接入之后，有些许不同）之后，就会期待收到用C-RNTI加扰的上行DCI（DCI format 0/4），此时它就会使用C-RNTI去盲检上行DCI。

如果此时UE还需要接收下行DCI，它就还会根据TM模式，用C-RNTI去解码下行DCI。也就是说，此时UE会接收2个DCI。UE自己清楚自己所处的状态，也知道在某个子帧，需要去尝试接收几个DCI。当然，可能出现UE期待接收2个DCI，但只检测到一个（可能eNodeB只发了一个）的情况，但UE都会尝试去盲检。也就是说，盲检次数可能大于44.

由于调度是在eNodeB侧实现的，UE无法预知自己何时会被调度到，也即无法预知自己会在哪个子帧上收到下行DCI和上行DCI，所以UE会一直去尝试盲检。

关于DCI盲检，我写过一篇文章，你可以参考一下。
http://blog.sina.com.cn/s/blog_927cff0101017tew.html

我感觉这样比较合理，多谢解惑了哈。
没想到原来是金兄，关注你博客好久了，之前还在你博客问了一个关于混合PUCCH fomat1/2里导频的问题还有印象没:lol

哈哈！有印象！到现在我还不知道是怎么回事！:lol