集群業務處理方法、裝置、基站及用戶設備的製作方法

2023-06-10 16:02:41

專利名稱：集群業務處理方法、裝置、基站及用戶設備的製作方法
技術領域：
本發明涉及通信領域，具體而言，涉及一種集群業務處理方法、裝置、基站及用戶設備。
背景技術：
集群通信系統是一種用於集團調度指揮通信的移動通信系統，主要應用在專業移動通信領域。目前存在集群通信系統有陸上集群無線電(Terrestrial Trunked Radio,簡稱為TETRA)系統、集成數字增強型網絡(Integrated Digital Enhanced Networks,簡稱為iDEN)系統、開放式集群架構(Global Open Trunking Architecture,簡稱為GoTa)系統以及GT800系統等。現有的集群通信系統都是基於第二代移動通信系統(2G)或者第三代移動通信系統(3 G)來實現。現有的集群通信系統可提供窄帶的語音業務和較低的數據業務速率。但·是隨著第四代移動通信系統(4G)和網際網路應用、智慧型手機的快速發展，社會各行業、企業用戶以及政府機關等集群用戶對數字集群通信系統的業務需求正在從普通的調度語音逐漸向語音、數據、圖像和視頻的寬帶多媒體的方向轉變，大帶寬和具有服務質量(QoS)保證的寬帶數字集群通信系統逐漸提上日程，但現有的數字集群通信系統越來越難於滿足上述要求。因此，在相關技術中存在的集群通信系統並不能滿足用戶更高的業務需求，以及提升更高的用戶體驗問題。

發明內容
本發明提供了一種集群業務處理方法、裝置、基站及用戶設備，以至少解決現有技術集群通信系統並不能滿足用戶業務需求，以及用戶體驗降低的問題。根據本發明的一個方面，提供了一種集群業務處理方法，包括基站生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息；所述基站將生成的所述調度信息發送給所述一個或多個UE。優選地，在所述基站生成用於對與所述一個或多個UE基於長期演進LTE系統進行集群業務的所述GTCH資源進行調度的調度信息之前，還包括所述基站為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置。優選地，所述基站為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置包括以下至少之一所述基站為所述一個或多個UE分配小區無線網絡臨時標識C-RNTI ；所述基站為所述一個或多個UE分配周期上報資源；所述基站為所述一個或多個UE分配保持上行同步方式和/或上行同步佔用的信道資源；所述基站為所述一個或多個UE分配群組無線網絡臨時標識Group-RNTI ;所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源，其中，進行所述HARQ的指示承載於物理上行控制信道TOCCH或者物理隨機接入信道PRACH。
優選地，在進行所述HARQ的指示承載於所述PUCCH的情況下，所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源包括以下至少之一所述基站為所述一個或多個UE分配用於所述GTCH的HARQ確認/非確認的發送格式；所述基站為所述一個或多個UE分配用於所述GTCH的HARQ確認/非確認的循環移位值；所述基站為所述一個或多個UE分配在每個傳輸時間間隔TTI中所述GTCH的HARQ的資源位置；或者，在進行所述HARQ的指示承載於所述PRACH的情況下，所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源包括以下至少之一所述PRACH的前導格式、所述PRACH的前導的頻譜位置，所述PRACH的前導的前導指數。優選地，所述基站將生成的所述調度信息發送給所述一個或多個UE包括所述基站將所述調度信息承載於物理下行控制信道roccH ;所述基站採用群組無線網絡臨時標識Group-RNTI對承載了所述調度信息的所述TOCCH進行標識和加擾；所述基站通過標識和加擾之後的所述HXXH向所述一個或多個UE發送所述調度信息。優選地，所述基站將生成的所述調度信息發送給所述一個或多個UE包括所述基 站通過預定子幀通知所述一個或多個UE所述HXXH是否承載了所述調度信息。優選地，在所述基站將生成的所述調度信息發送給所述一個或多個UE之後，還包括在接收到來自所述UE的非確認信息的情況下，所述基站重傳所述GTCH信道的調度信
肩、O根據本發明的另一方面，提供了一種集群業務處理方法，包括用戶設備UE接收用於對與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息；所述UE判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功；在所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功的情況下，所述UE向所述基站發送非確認信息。優選地，所述UE判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述roSCH是否成功包括所述UE判斷所述基站是否向所述UE發送了採用Group-RNTI標識和加擾的物理下行控制信道TOCCH，以及所述基站是否通過預定子幀通知所述UE所述HXXH中是否存在所述GTCH的調度信息，其中，所述HXXH承載有所述調度信息；在判斷結果為是的情況下，所述UE判斷根據採用Group-RNTI標識和加擾的所述HXXH是否能夠接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道H)SCH是否成功；在判斷結果為否的情況下，確定所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功。根據本發明的再一方面，提供了一種集群業務處理裝置，包括生成模塊，用於生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息；第一發送模塊，用於將生成的所述調度信息發送給所述一個或多個UE。優選地，還包括第一配置模塊，用於為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置。優選地，所述第一發送模塊包括承載單元，用於將所述調度信息承載於物理下行控制信道HXXH ;加擾單元，用於採用群組無線網絡臨時標識Group-RNTI對承載了所述調度信息的所述roccH進行標識和加擾；發送單元，用於通過標識和加擾之後的所述roccH向所述一個或多個UE發送所述調度信息。優選地,還包括通知模塊，用於通過預定子巾貞通知所述一個或多個UE所述F1DCCH是否承載了所述調度信息。根據本發明的再一方面，提供了一種基站，包括上述任一項所述裝置。根據本發明的又一方面，提供了一種集群業務處理裝置，包括接收模塊，用於接收用於對與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息；第一判斷模塊，用於判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功；第二發送模塊，用於在所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功的情況下，向所述基站發送非確認信息。 優選地，所述第一判斷模塊包括第一判斷單元，用於判斷所述基站是否向所述UE發送了採用Group-RNTI標識和加擾的物理下行控制信道TOCCH，以及所述基站是否通過預定子幀通知所述UE所述HXXH中是否存在所述GTCH的調度信息，其中，所述HXXH承載有所述調度信息；第二判斷單元，用於在所述第一判斷單元的判斷結果為是的情況下，判斷根據採用Group-RNTI標識和加擾的所述TOCCH是否能夠接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道H)SCH是否成功；確定單元，用於在所述第二判斷單元的判斷結果為否的情況下，確定所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述roSCH不成功。根據本發明的還一方面，提供了一種用戶設備，包括上述任一項所述裝置。通過本發明，採用基站生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH進行調度的調度信息；所述基站將生成的所述調度信息發送給所述一個或多個UE，解決了集群通信系統並不能滿足用戶業務需求，以及用戶體驗降低的問題，進而達到了滿足用戶基於LTE系統的集群業務需求，以及提高用戶體驗的效果。


此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用於解釋本發明，並不構成對本發明的不當限定。在附圖中圖I是根據本發明實施例的集群業務處理方法的流程圖一；圖2是根據本發明實施例的集群業務處理方法的流程圖二 ；圖3是根據本發明實施例的集群業務處理裝置的結構框圖一；圖4是根據本發明實施例的集群業務處理裝置的優選結構框圖一；圖5是根據本發明實施例的集群業務處理裝置中第一發送模塊34的優選結構框圖一；圖6是根據本發明實施例的集群業務處理裝置中第一發送模塊34的優選結構框圖二 ；圖7是根據本發明實施例的基站的結構框圖；圖8是根據本發明實施例的集群業務處理裝置的結構框圖二 ；
圖9是根據本發明實施例的集群業務處理裝置中第一判斷模塊74的優選結構框圖；圖10是根據本發明實施例的用戶設備的結構框圖；圖11是根據本發明實施例的集群業務信道GTCH映射的示意圖；圖12為根據本發明實施例的群組建立方法的示意圖；圖13是根據本發明實施例的基站向非話權用戶指派群組GTCH的HARQ資源的示意圖；圖14是根據本發明實施例的基站對非話權用戶進行群組GTCH調度和HARQ的示意圖。
具體實施例方式下文中將參考附圖並結合實施例來詳細說明本發明。需要說明的是，在不衝突的情況下，本申請中的實施例及實施例中的特徵可以相互組合。長期演進技術(Long Term Evolution,簡稱為LTE)已正在成為一種主流的4G通信技術，也是未來通信發展的主流，LTE協議是面向點對點的通訊協議，基於LTE技術的集群通信系統，具有LTE技術天生的技術優勢，基於LTE技術的集群通信系統可提供大帶寬和具有服務質量(QoS)保證的各種業務，例如，語音、視頻、圖像等。針對上述問題，在本實施例中提供了一種如何利用LTE技術來提供更大帶寬和QoS服務質量的集群通信業務的方法，下面結合附圖對本實施例進行說明。在本實施例中提供了一種集群業務處理方法，圖I是根據本發明實施例的集群業務處理方法的流程圖一，如圖I所示，該流程包括如下步驟步驟S102，基站生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH進行調度的調度信息；步驟S104，基站將生成的調度信息發送給上述一個或多個UE。通過上述步驟，在基於現有LTE系統保留單播的LTE協議的情況下，通過新增用於集群業務的資源配置，並將資源配置的資源配置信息發送給集群業務範圍內的UE，相對於現有技術中基於2G、3G的集群業務，或者現有的LTE無法應用集群業務，不僅滿足了用戶基於LTE系統的集群業務需求，而且在一定程度上提高了用戶體驗。在基站生成用於與一個或多個UE基於長期演進LTE系統進行集群業務的該調度信息之前，可以先為與上述一個或多個UE進行集群業務的資源進行配置。對集群業務的資源分配所涉及的內容可以很多，例如，基站為與上述一個或多個UE進行集群業務的資源進行分配可以包括以下至少之一基站為一個或多個UE分配小區無線網絡臨時標識(Cell-Radio Network Temporary Identif ier,簡稱為 C-RNTI);基站為一個或多個UE分配周期上報資源；基站為一個或多個UE分配保持上行同步方式和/或上行同步佔用的信道資源；基站為一個或多個UE分配群組無線網絡臨時標識Group-RNTI ;基站為一個或多個UE分配用於GTCH進行混合自動重傳請求HARQ的資源，基站為一個或多個UE分配用於GTCH進行混合自動重傳請求HARQ指示(也即UE沒有成功接收到上述調度信息的非確認指示信息)，該指示可以承載在物理上行鏈路控制信道(Physical Uplink Control CHannel,簡稱為PUCCH)信道上，也可承載在物理隨機接入信道(PhysicalRandom Access Channel,簡稱為PRACH)信道上。例如，在進行HARQ指示承載在PUCCH信道上的情況下，基站為一個或多個UE分配用於GTCH進行混合自動重傳請求HARQ的資源又可以包括以下至少之一基站為一個或多個UE分配用於GTCH的HARQ確認/非確認的發送格式；基站為一個或多個UE分配用於GTCH的HARQ確認/非確認的循環移位值；基站為一個或多個UE分配在每個傳輸時間間隔TTI中GTCH的HARQ的資源位置。在進行HARQ指示承載在PRACH信道上的情況下，基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源可以包括以下至少之一 PRACH的前導(preamble)格式、PRACH的preamble的頻譜位置或資源塊(Resource Block,簡稱為 RB)具體位置,PRACH 的 preamble 的 preamble 指數(36. 331 協議的 PRACH 的 PreambIeIndex)。基站將生成的調度信息發送給一個或多個UE也可以採用多種方式，例如，可以通過新構造一個通知信息的方式，也可以將調度信息承載於一個已有信息中進行發送，在本實施例中提供了一種優選的處理方式基站將調度信息承載於物理下行控制信道HXXH ；基站採用群組無線網絡臨時標識Group-RNTI對承載了調度信息的HXXH進行標識和加擾；基站通過標識和加擾之後的該HXXH向一個或多個UE發送調度信息。採用這樣的處理方式，不僅可以在有效地利用現有的roccH資源，而且在一定程度上保證了基站向一個或多個UE發送調度信息的可靠性。由於通過Group-RNTI標識和加擾的HXXH在非話權終端側·接收時存在誤包的可能，為保證非話權終端能可靠知曉是否在HXXH中存在GTCH信道產生調度結果和資源分配信息(即，調度信息)，eNodeB在子幀X (預定子幀上)通知群組非話權終端在子幀X是否存在群組A的Group-RNTI標識和加擾的TOCCH。在基站將生成的調度信息發送給一個或多個UE之後，在接收到來自UE的非確認信息的情況下，基站重傳GTCH信道的調度信息。即，在UE向基站發送非確認信息之後，基站進行群組A的GTCH信道重傳，重傳所採用的方式可以如前所述。在本實施例中還提供了一種集群業務處理方法，圖2是根據本發明實施例的集群業務處理方法的流程圖二，如圖2所示，該流程包括如下步驟步驟S202，用戶設備UE接收用於對與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH進行調度的調度信息；步驟S204，UE判斷是否成功接收到上述調度信息，和/或，根據調度信息解碼GTCH映射的物理下行共享信道roscH是否成功；步驟S206，在UE沒有成功接收到上述調度信息，和/或，根據上述調度信息解碼GTCH映射的roSCH不成功的情況下，該UE向基站發送非確認信息。UE判斷是否成功接收到調度信息對應的GTCHdP /或，根據上述調度信息解碼GTCH映射的roSCH是否成功時，可以通過以下較優的方式進行判定UE判斷基站是否向UE發送了採用Group-RNTI標識和加擾的物理下行控制信道TOCCH，以及基站是否通過預定子幀通知UE所述HXXH中是否存在GTCH的調度信息，其中，該I3DCCH承載有上述調度信息；在判斷結果均為是的情況下，UE判斷根據採用Group-RNTI標識和加擾的HXXH是否能夠接收到上述調度信息，和/或，根據GTCH的調度信息解碼GTCH映射的物理下行共享信道PDSCH是否成功；在根據採用Group-RNTI標識和加擾的I3DCCH不能夠接收到上述調度信息時，也即基站指示有該GTCH的調度信息，但所述UE無法接收到該GTCH的調度信息，即可以確定UE沒有成功接收到調度信息，該UE可以向基站發送非確認信息。而在UE能夠接收到該GTCH的調度信息之後，如果根據該調度信息解碼GTCH映射的I3DSCH不成功，用戶也可以向基站發送不確認信息。即，在上述的判斷步驟中只要其中一個步驟存在判斷結果為否，UE就可以向基站發送不確認信息。而在向基站發送了不確認信息之後，基站得知上述UE (非話權終端)接收失敗，因而，基站向UE重傳GTCH，繼而UE接收到來自基站重傳的對GTCH資源進行調度的調度信息時，採用上述相同的判斷處理方式確定重傳是否成功。在本實施例中還提供了一種集群業務處理裝置，該裝置用於實現上述實施例及優選實施方式，已經進行過說明的不再贅述。如以下所使用的，術語「模塊」可以實現預定功能的軟體和/或硬體的組合。儘管以下實施例所描述的裝置較佳地以軟體來實現，但是硬體，或者軟體和硬體的組合的實現也是可能並被構想的。圖3是根據本發明實施例的集群業務處理裝置的結構框圖一，如圖3所示，包括生成模塊32和第一發送模塊34，下面對該裝置進行說明。·
生成模塊32，用於生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH進行調度的調度信息；第一發送模塊34，連接至上述生成模塊32，用於將生成的上述調度信息發送給一個或多個UE。圖4是根據本發明實施例的集群業務處理裝置的優選結構框圖一，如圖4所示，該裝置除包括圖3所示的所有模塊外，還包括第一配置模塊42，下面對該優選裝置進行說明。第一配置模塊42，連接至上述生成模塊32，用於為與一個或多個UE進行集群業務的GTCH資源進行配置。圖5是根據本發明實施例的集群業務處理裝置中第一發送模塊34的優選結構框圖一，如圖5所示，該第一發送模塊34包括承載單元52、加擾單元54和發送單元56，下面對該優選結構進行說明。承載單元52，用於將調度信息承載於物理下行控制信道HXXH ;加擾單元54，連接至上述承載單元52，用於採用群組無線網絡臨時標識Group-RNTI對承載了調度信息的PDCCH進行標識和加擾；發送單元56，連接至上述加擾單元54，用於通過標識和加擾之後的PDCCH向一個或多個UE發送調度信息。圖6是根據本發明實施例的集群業務處理裝置中第一發送模塊34的優選結構框圖二，如圖6所示，該第一發送模塊34包括通知單元62，該通知單元62，用於通過預定子幀通知上述一個或多個UE所I3DCCH是否承載了調度信息。圖7是根據本發明實施例的基站的結構框圖，如圖7所示，該基站70包括圖3至圖6其中之一的集群業務處理裝置72。圖8是根據本發明實施例的集群業務處理裝置的結構框圖二，如圖8所示，該裝置位於用戶設備UE中，包括接收模塊82、第一判斷模塊84和第二發送模塊86，下面對該裝置進行說明。接收模塊82，用於接收用於與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH進行調度的調度信息；第一判斷模塊84，連接至上述接收模塊82，用於判斷是否成功接收到上述調度信息，和/或，根據上述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功；第二發送模塊86，連接至上述第一判斷模塊84，用於在UE沒有成功接收到上述調度信息，和/或，根據上述調度信息解碼GTCH映射的H)SCH不成功的情況下，向基站發送非確認信息。圖9是根據本發明實施例的集群業務處理裝置中第一判斷模塊84的優選結構框圖，如圖9所示，該第一判斷模塊包括第一判斷單元92、第二判斷單元94和確定單元96，下面對該第一判斷模塊94進行說明。第一判斷單元92,用於判斷基站是否向UE發送了採用Group-RNTI標識和加擾的物理下行控制信道H)CCH，以及基站是否通過預定子幀通知UE PDCCH中是否存在GTCH的調度信息，其中，PDCCH承載有調度信息；第二判斷單元94，連接至上述第一判斷單元92，用於在第一判斷單元92的判斷結果為是的情況下，判斷根據採用Group-RNTI標識和加擾的PDCCH是否能夠接收到上述調度信息，和/或，根據上述調度信息解碼GTCH映射的物理下行共享信道roSCH是否成功；確定單元96，連接至上述第二判斷單元94，用於在第二判斷單元94的判斷結果為否的情況下，確定該UE沒有成功接收到上述調度信息，和/或，根據上述調度信息解碼GTCH映射的I3DSCH不成功。 圖10是根據本發明實施例的用戶設備的結構框圖，如圖10所示，該用戶設備100包括圖8至圖9其中之一的集群業務處理裝置102。上述實施例及優選實施方式所提供的基於長期演進LTE技術的寬帶數字集群通信系統以及集群系統空口實現方法，不僅較大地提高了資源利用率，而且在一定程度上有益地改善了小區空口容量。在上述實施例及優選實施方式所提供的集群業務實現方法中，主要包括在基於LTE技術的數字通信協議基礎上，保留單播的LTE協議，針對集群(下行)業務點對多點的特點，新增對該集群業務的處理方式例如新增用於實現下行集群業務的邏輯信道和傳輸信道，其中，該邏輯信道可以為集群業務信道GTCH，圖11是根據本發明實施例的集群業務信道GTCH映射的示意圖，如圖11所示，該GTCH信道的映射方式為GTCH信道一下行共享信道DL SCH — PDSCH信道；新增適合點對多點的下行GTCH信道的HARQ方法；新增點對多點的信道質量指示(Channel Quality Indication,簡稱為CQI)上報方法；新增點對多點的調製編碼方案(Modulation and Coding Scheme,簡稱為MCS)的生成方法等。本實施例所提供的集群業務實現方法包括幾個部分(或稱，幾個子方法)，需要說明的是，上述幾個部分可以是其中分別獨立的一個部分，當然也可以將上述幾個部分進行隨意組合。群組建立子方法A 步驟1，組呼話權終端發起群組A的組呼請求，eNodeB在規定的組呼尋呼周期時刻發起群組A內所有非話權終端的組尋呼消息(GroupPage)。步驟2，群組內非話權終端收到組尋呼消息GroupPage後發送尋呼響應(PageResponse),假設群組A內任一非話權終端編號為User [i]，其收到尋呼消息後，發送尋呼響應消息為PageResponse [i]。步驟3, eNodeB收到PageResponse [i]尋呼響應後，eNodeB為非話權終端分配如下資源(I)分配 User[i]的 C-RNTI (對應於 3GPP TS 36. 331 協議的 Cell RNTI),即為C-RNTI[i]。(2)分配CQI周期上報資源(包括周期和上報時間偏置、上報模式、在TOCCH上報位置資源等)，例如，可以通過36. 331協議中的CQI-ReportConfig配置。(3)分配保持上行同步方式和上行同步佔用的信道資源(保持上行同步的方式有很多種，例如，周期發起Sounding的方式、周期發起SR資源請求的方式,周期上報CQI的方式，周期發起PRACH的方式，周期發起數據的方式等)(4) Group-RNTI (群組內終端分配相同的RNTI)步驟4，建立該群組A的GTCH信道，GTCH信道使用Group-RNTI進行標識和調度。群組上行定時同步子方法B :步驟I :終端按照上述子方法A指定的保持上行同步方式和上行同步佔用的信道資源，保持和eNodeB上行同步。 步驟2 eNodeB周期發送定時提前命令，終端調整上下行無線幀的定時偏置即Nta (36. 311協議中的Nta)。CQI上報和處理子方法C 步驟1，User[i]終端按照eNodeB規定的CQI上報方式發起周期CQI上報。步驟2，在eNodeB，根據群組內每個非話權終端上報的CQI [i]，根據一定的算法計算出該群組GTCH的調製編碼方案MCS。GTCH信道的HARQ資源指派子方法D GTCH進行混合自動重傳請求HARQ指示(也即非確認指示)，承載在PUCCH信道上，也可承載在PRACH信道上。當HARQ指示承載在承載在PUCCH信道上，採用步驟la，當HARQ指示承載在承載在PRACH信道上，採用步驟lb。步驟la，eNodeB指派GTCH信道的HARQ資源包括以下內容至少之一(I) eNodeB分配承載在I3UCCH上用於GTCH信道的HARQ ACK/NAK的發送格式(PUCCH format),可米用 format I, format la/lb, format 2a/2b 等格式的一種。(2 )eNodeB分配用於承載GTCH信道的HARQ ACK/NAK的PUCCH的循環移位值(3GPPTS36. 311 協議的A=fH)。 (3) eNodeB決定用於承載GTCH信道的HARQ ACK/NAK的PUCCH的資源位置是eNodeB額外指定，還是根據承載GTCH資源調度信息的物理下行控制信道(PhysicalDownlink Control Channel，簡稱為 PDCCH)的 nCCE (nCCE 為 PDCCH 的第一個 CCE 的位置，依據 36. 213 協議中的 UE procedure for determining physical uplink control channelassignment章節進行計算)進行計算得到。如果是eNodeB指定,則eNodeB必須在每個傳輸時間間隔(Transmission Time Interval，簡稱為TTI)顯示指明GTCH信道的HARQ ACK/NAK的PUCCH的資源位置。步驟Ib，eNodeB指派GTCH信道的HARQ資源包括以下內容至少之一(I)當非話權用戶向eNodeB發送GTCH解碼是否成功的非確認指示時,非確認指示觸發PRACH信道的Preamble發送；(2)eNodeB為群組A所有的非話權用戶指派承載HARQ指示的相同preamble格式(36. 331協議中的preamble format O 3), preamble在整個上行帶寬的RB具體位置；(3)eNodeB為群組A所有的非話權用戶指派承載HARQ指示的相同preamble指數(36. 331 協議的 PRACH 的 PreambleIndex)；(4)eNodeB為群組A所有的非話權用戶指派承載HARQ指示的preamble的發射功率參數(如初始化發送功率參數)。步驟2，eNodeB分配以上信息之後通過空口通知群組A的每個非話權終端。群組GTCH信道的調度和GTCH信道的HARQ子方法E 步驟I，在eNodeB，當有群組下行數據到達時，在某個子幀X調度器進行調度時，對群組A的GTCH信道產生調度結果和資源分配信息(包括，RB位置、RB數目、MCS等)，調度結果和資源分配信息通過I3DCCH承載，PDCCH通過Group-RNTI標識和加擾。需要說明的是，在步驟I中，當GTCH信道採用半靜態分配(也即semi-static resource allocation,簡稱為SPS),則資源分配信息周期不變。子方法E還可包括，步驟2 :步驟2，因為步驟I中通過Group-RNTI標識和加擾的HXXH在非話權終端側接收時存在誤包的可能，為保證非話權終端能可靠知曉是否在roccH中存在GTCH信道產生調度結果和資源分配信息，eNodeB在子幀X通知群組非話權終端在子幀X是否存在群組A的Group-RNTI標識和加擾的HXXH (承載GTCH信道的調度結果和資源分配信息)，eNodeB在子幀X通知群組非話權終端的方式可以為如下幾種，但不僅僅限於如下幾種(I)構造下行鏈路控制信息(Downlink Control Information,簡稱為DCI)格式，DCI信息中包含在子幀X已調度的群組編號，在HXXH中承載，通過特殊的RNTI標識和加擾。(2)構造一種資源指派消息，資源指派消息包含在子幀X已調度的群組編號，資源指派消息承載在roscH。非話權終端判斷在子幀X是否存在群組A的Group-RNTI標識和加擾的HXXH(承載GTCH信道的調度結果和資源分配信息)。若存在，則認為條件M為是，若不存在，則條件M為否。步驟3，非話權終端在roCCH搜索空間範圍內搜索Group-RNTI標識和加擾的PDCCH，按照如下判決規則進行判決針對步驟1，如果子幀X存在Group-RNTI標識和加擾的TOCCH，則條件P為是。如果子幀X不存在Group-RNTI標識和加擾的TOCCH，則條件P為否。如果條件P為是，根據HXXH的資源分配信息解碼GTCH信道映射的物理下行共享信道(Physical Downlink Shared Channel，簡稱為PDSCH)，若解碼GTCH信道映射的物理信道I3DSCH成功(CRC解碼成功)，則條件Z為是。若解碼GTCH信道映射的物理信道I3DSCH不成功(CRC解碼不成功)，則條件Z為否。如果存在步驟2，則進行如下判決若步驟2的條件M為是，但條件P為否，則條件Z為否。根據如上判決，如果條件Z為是，則不需要執行步驟4，如果條件Z為否，需要執行步驟4，當需要執行步驟4則非話權終端認為在子幀X存在群組A的GTCH信道，但非話權終端對群組A的GTCH信道解碼不成功，非話權終端需要發送GTCH信道的NACK反饋給eNodeB。群組在小區內存在多個非話權終端，組內只要有任何一個終端承載GTCH信道的NACK的PUCCH (物理上行控制信道)或者PRACH (物理隨機接入信道)中反饋NACK，則eNodeB會認為此調度至少有一個非話權終端接收失敗，需要重傳。步驟4，GTCH信道對應的NACK可承載在PUCCH上，也可承載在PRACH信道上。
當HARQ指示承載在PUCCH信道上，終端物理PUCCH上行控制信道中反饋在GTCH信道對應的NACK，PUCCH格式可以採用上述子方法D的步驟Ia來指定，PUCCH的循環移位值可以採用上述子方法D的步驟Ia來指定，PUCCH的資源位置可以根據上述子方法D的步驟Ia來指定。當HARQ指示承載在PRACH信道上，PRACH信道的Preamble發送方法和參數通過上述子方法D的步驟Ib來指定步驟5，eNodeB嘗試承載GTCH信道對應NAK的PUCCH上接收NACK或者嘗試捕獲GTCH信道對應NAK的Preamble，如果存在NACK，則認為需要重傳，eNodeB進行群組A的GTCH信道重傳。反之，則不需要重傳。對於上述所說明的子方法A、子方法B、子方法C、子方法D、子方法E，每個子方法都是可以以單獨形成的一個功能實施，當然在不相衝突的情況下，也可以將上述子方法進行 相互組合。需要指出的是，上述單獨或是組合的實施例及優選實施方式不僅適合於小區內群組非話權用戶數目適中的情況，還適用於小區內群組非話權用戶很多的情況，對於所屬技術領域的技術人員而言，從對本發明實施例的詳細說明中，本發明實施例的上述和其他目的、特徵和優點將顯而易見。下面針對上述單獨的各個子方法，以及各個子方法的結合進行具體說明。群組建立子方法A :圖12為根據本發明實施例的群組建立方法的示意圖，如圖12所示，群組建立大致包括群組尋呼過程、群組尋呼響應處理過程和非話權用戶進入RRC連接狀態，具體可以包括如下步驟步驟1，組呼話權終端發起群組A的組呼請求，eNodeB在規定的組呼尋呼周期時刻發起群組A內所有非話權終端的組尋呼消息(GroupPage)。步驟2，群組內非話權終端收到組尋呼消息GroupPage後發送尋呼響應(PageResponse)，假設群組A內任一非話權終端編號為User [i]，其收到尋呼消息後，發送尋呼響應消息為PageResponse [i]。步驟3, eNodeB收到PageResponse [i]尋呼響應後，eNodeB為非話權終端分配如下資源(I)分配 User[i]的 C-RNTI (對應於 3GPP TS 36。331 協議的 Cell RNTI，小區內每個)，即為C-RNTI [i]。(2)CQI周期上報資源(包括周期和上報時間偏置、上報模式、在PUCCH信道上報位置資源等)，可以通過36。213協議中的CQI-ReportConfig等方式指派。(3)保持上行同步方式和上行同步佔用的信道資源(保持上行同步的方式有很多種，如周期發起Sounding的方式、周期發起SR資源請求的方式，周期上報CQI的方式，周期發起PRACH的方式，周期發起數據的方式等)。(4) Group-RNTI (群組內終端分配相同的RNTI )。在分配了上述資源之後，eNodeB和User[i]建立RRC連接(RRC CONNECTION),eNodeB將分配的上述信息通過空中接口指派給群組A的每個非話權終端。步驟4，建立該群組A的GTCH信道，GTCH信道使用Group-RNTI進行標識和調度。步驟5，User [i]進入RRC CONNECTION STATE狀態，可同時進行如下子方法B、子方法C、子方法D和子方法E。 群組上行定時同步子方法B:步驟I :UE按照如下方法之一保持和eNodeB上行定時同步，保持上行同步的方式有很多種，例如，周期發起Sounding的方式，周期發起數據的方式，周期發起SR資源請求的方式，周期上報CQI的方式，周期發起PRACH的方式。步驟2 eNodeB周期發送定時提前命令，終端調整上下行無線幀的定時偏置即Nta(36. 311協議中的Nta)。CQI上報和處理子方法C 步驟1，User[i]終端按照eNodeB規定的CQI上報方式發起周期CQI上報。步驟2，群組A根據群組內每個非話權終端上報的CQI [i]，eNodeB根據一定的算 法計算出該群組下的MCS[A]，用於GTCH信道的調製和編碼。群組GTCH的HARQ資源指派子方法D，圖13是根據本發明實施例的基站向非話權用戶指派群組GTCH的HARQ資源的示意圖，如圖13所示，基站向非話權用戶周期發送GTCH的HARQ資源位置列表消息，例如，eNodeB周期在空口發送GroupDLHARQResourceParameter消息可以包括(I) NormalDLHARQffay 當 NormalDLHARQWay 為 I 時，群組 GTCH 的 HARQ 時佔用PUCCH的資源採用36. 213協議中的PUCCH資源計算方法，根據承載GTCH資源調度信息的PDCCH 的 nCCE(nCCE 為 PDCCH 的第一個 CCE 的位置，依據 36. 213 協議中的 UE procedure fordetermining physical uplink control channel assignment 章節進行計算)進行計算得到。當NormalDLHARQWay為O時，群組GTCH的HARQ時佔用PUCCH的資源採用另外指定的方法，即採用上述實施例中子方法E的方法。(2) deItaGroupPUCCHShift 指定用於群組 GTCH 下行 HARQ 時進行PUCCHFormatl/la/lb 的循環移位值。(3 ) GroupDLHARQPUCCHFormat :群組下行 HARQ 時在 PUCCH 的 PUCCH format 方式，在此實施例中採用Format I格式。(4)群組GTCH的HARQ資源位置和HARQ資源位置編號，資源位置表達為承載GTCHHARQ的PUCCH的RB位置，在此實施例中採用Format I格式，採用類似SR Request方法，如果為NACK，在PUCCH的Formatl的信息位d (O)為I (具體參見36. 211)，如果為ACK,則PUCCH Formatl不發送任何信號,GroupDLHARQResourceParameter消息發送方法包括如下，但不僅限於如下幾種方法類似於System information的發送方式,周期發送。群組GTCH調度和HARQ子方法E，圖14是根據本發明實施例的基站對非話權用戶進行群組GTCH調度和HARQ的示意圖，如圖14所示，該處理包括基站向非話權用戶發送群組調度DCI和群組DCI指派的H)SCH、指派DTCH的HARQ資源，以及非話權用戶在PUCCH上採用Parmatl格式反饋非確認NACK。例如,處理時可以包括如下步驟步驟1，在eNodeB，當有群組下行數據到達時，在某個子幀X調度器進行調度時，對群組A產生調度結果(包括RB位置、RB數目、MCS等)，調度結果承載在DCI中，DCI格式不限，假設為DCI Y，通過PDCCH下發，PDCCH通過Group-RNTI加擾和標識。步驟I，在eNodeB，當有群組下行數據到達時，在某個子幀X調度器進行調度時，對群組A的GTCH信道產生調度結果和資源分配信息(包括，RB位置、RB數目、MCS等)，調度結果和資源分配信息通過HXXH承載，PDCCH通過Group-RNTI標識和加擾。需要說明的是，在步驟I中，當GTCH信道可以採用半靜態分配，則資源分配信息周期不變。子方法E還可包括，步驟2 步驟2，因為步驟I中通過Group-RNTI標識和加擾的HXXH在非話權終端側接收時有可能誤包，為保證非話權終端能可靠知曉是否在roccH中存在GTCH信道的調度結果和資源分配信息，eNodeB在子幀X通知群組非話權終端在子幀X是否存在群組A的Group-RNTI標識和加擾的I3DCCH (承載GTCH信道的調度結果和資源分配信息)，eNodeB在子幀X通知群組非話權終端的方式可以為如下幾種步驟2a，當某子幀X調度完後，構造一種DCI格式，假設為DCI 1G,DCI IG可以為 36.212協議中的已有的DCI格式或者新的DCI格式，DCI格式中內容包含了在子幀X已調度的群組編號和已調度群組對應的在GroupDLHARQResourceParameter消息中的DLHARQ資源編號，通過群組公用的Group-RNTI加擾，PDCCH位置放在公用搜索空間，在TOCCH中發送。而且在DCIlG中指定使用HARQ資源編號。步驟2b，當某子幀X調度完後，構造一種GroupDLHARQ資源指派消息，GroupDLHARQ資源指派消息包含在子幀X已調度的群組編號和已調度群組對應的在GroupDLHARQResourceParameter 消息中的 DLHARQ 資源位置編號，GroupDLHARQ 資源指派消息通過I3DSCH來承載發送。執行步驟2a或者步驟2b，非話權終端判斷在子幀X是否存在群組A的Group-RNTI標識和加擾的roCCH (承載GTCH信道的調度結果和資源分配信息)。若存在，則認為條件M為是，若不存在，則條件M為否。步驟3，非話權終端在roCCH搜索空間範圍內搜索Group-RNTI標識和加擾的PDCCH，按照如下判決規則進行判決如果子幀X存在Group-RNTI標識和加擾的TOCCH，則條件P為是。如果子幀X不存在Group-RNTI標識和加擾的TOCCH，則條件P為否。如果條件P為是，根據HXXH的資源分配信息解碼GTCH信道映射的物理信道PDSCH，若解碼GTCH信道映射的物理信道I3DSCH成功(CRC解碼成功)，則條件Z為是。若解碼GTCH信道映射的物理信道I3DSCH不成功(CRC解碼不成功)，則條件Z為否。如果存在步驟2，則進行如下判決若步驟2的條件M為是，但條件P為否，則條件Z為否。根據如上判決，如果條件Z為是，則不需要執行步驟4，如果條件Z為否，需要執行步驟4，當需要執行步驟4則非話權終端認為在子幀X存在群組A的GTCH信道，但非話權終端對群組A的GTCH信道解碼不成功，非話權終端需要發送GTCH信道的NACK反饋給eNodeB。群組在小區內存在多個非話權終端，組內只要有任何一個終端承載GTCH信道的NACK的PUCCH上行信道中反饋NACK，則eNodeB會認為此調度至少有一個非話權終端接收失敗，需要重傳。步驟4, PUCCH上按照GroupDLHARQResourceParameter消息中指示的格式承載NACK，採用上述子方法E的步驟2中指示的本組資源編號，通過資源編號映射資源位置，表達為RB位置和在PUCCH的PUCCH format方式，以及PUCCH資源。發送NACK 時，d(0)=l，採用 PUCCH Formatl 的格式發送，當 NormalDLHARQWay 為O時，則根據本子方法的步驟2的本組資源編號，在GroupDLHARQResourceParameter消息找到本組資源編號對應的值，Δ= 使用deltaGroupPUCCHShift值，通過PUCCH的Formatl來發送。發送NACK 時，d (O)=I，採用 PUCCH Formatl 的格式發送，當 NormalDLHARQWay 為 I時，則根據36. 213協議的方法來計算#1# 的值,Δ= 使用deltaGroupPUCCHShift值，通過PUCCH的Formatl來發送。步驟5，eNodeB嘗試承載GTCH信道對應NAK的PUCCH上接收NACK，如果存在NACK，則認為需要重傳，eNodeB進行群組A的GTCH信道重傳。反之，則不需要重傳。通過上述實施例及優選實施方式，不但能夠縮短呼叫建立時間，而且能夠提高資源利用率。
·
顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，並且在某些情況下，可以以不同於此處的順序執行所示出或描述的步驟，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模塊或步驟製作成單個集成電路模塊來實現。這樣，本發明不限制於任何特定的硬體和軟體結合。以上所述僅為本發明的優選實施例而已，並不用於限制本發明，對於本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
權利要求
1.一種集群業務處理方法，其特徵在於，包括 基站生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息； 所述基站將生成的所述調度信息發送給所述一個或多個UE。
2.根據權利要求I所述的方法，其特徵在於，在所述基站生成用於對與所述一個或多個UE基於長期演進LTE系統進行集群業務的所述GTCH資源進行調度的調度信息之前，還包括 所述基站為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置。
3.根據權利要求2所述的方法，其特徵在於，所述基站為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置包括以下至少之一 所述基站為所述一個或多個UE分配小區無線網絡臨時標識C-RNTI ； 所述基站為所述一個或多個UE分配周期上報資源； 所述基站為所述一個或多個UE分配保持上行同步方式和/或上行同步佔用的信道資源； 所述基站為所述一個或多個UE分配群組無線網絡臨時標識Group-RNTI ； 所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源，其中，進行所述HARQ的指示承載於物理上行控制信道PUCCH或者物理隨機接入信道PRACH。
4.根據權利要求3所述的方法，其特徵在於， 在進行所述HARQ的指示承載於所述TOCCH的情況下，所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源包括以下至少之一所述基站為所述一個或多個UE分配用於所述GTCH的HARQ確認/非確認的發送格式；所述基站為所述一個或多個UE分配用於所述GTCH的HARQ確認/非確認的循環移位值；所述基站為所述一個或多個UE分配在每個傳輸時間間隔TTI中所述GTCH的HARQ的資源位置；或者， 在進行所述HARQ的指示承載於所述PRACH的情況下，所述基站為所述一個或多個UE分配用於所述GTCH進行混合自動重傳請求HARQ的資源包括以下至少之一所述PRACH的前導格式、所述PRACH的前導的頻譜位置，所述PRACH的前導的前導指數。
5.根據權利要求I所述的方法，其特徵在於，所述基站將生成的所述調度信息發送給所述一個或多個UE包括 所述基站將所述調度信息承載於物理下行控制信道roccH ； 所述基站採用群組無線網絡臨時標識Group-RNTI對承載了所述調度信息的所述PDCCH進行標識和加擾； 所述基站通過標識和加擾之後的所述roccH向所述一個或多個UE發送所述調度信息。
6.根據權利要求5所述的方法，其特徵在於，所述基站將生成的所述調度信息發送給所述一個或多個UE包括 所述基站通過預定子幀通知所述一個或多個UE所述roCCH是否承載了所述調度信息。
7.根據權利要求I所述的方法，其特徵在於，在所述基站將生成的所述調度信息發送給所述一個或多個UE之後,還包括 在接收到來自所述UE的非確認信息的情況下，所述基站重傳所述GTCH信道的調度信肩、O
8.一種集群業務處理方法，其特徵在於，包括 用戶設備UE接收用於對與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息； 所述UE判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功； 在所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功的情況下，所述UE向所述基站發送非確認信息。
9.根據權利要求8所述的方法，其特徵在於，所述UE判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述roSCH是否成功包括 所述UE判斷所述基站是否向所述UE發送了採用Group-RNTI標識和加擾的物理下行控制信道roccH，以及所述基站是否通過預定子幀通知所述UE所述HXXH中是否存在所述GTCH的調度信息，其中，所述HXXH承載有所述調度信息； 在判斷結果為是的情況下，所述UE判斷根據採用Group-RNTI標識和加擾的所述HXXH是否能夠接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功； 在判斷結果為否的情況下，確定所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述I3DSCH不成功。
10.一種集群業務處理裝置，其特徵在於，包括 生成模塊，用於生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息； 第一發送模塊，用於將生成的所述調度信息發送給所述一個或多個UE。
11.根據權利要求10所述的裝置，其特徵在於，還包括 第一配置模塊，用於為與所述一個或多個UE進行集群業務的所述GTCH資源進行配置。
12.根據權利要求10所述的裝置，其特徵在於，所述第一發送模塊包括 承載單元，用於將所述調度信息承載於物理下行控制信道HXXH ； 加擾單元，用於採用群組無線網絡臨時標識Group-RNTI對承載了所述調度信息的所述I3DCCH進行標識和加擾； 發送單元，用於通過標識和加擾之後的所述roccH向所述一個或多個UE發送所述調度信息。
13.根據權利要求10所述的裝置，其特徵在於，所述第一發送模塊包括 通知單元，用於通過預定子幀通知所述一個或多個UE所述HXXH是否承載了所述調度信息。
14.一種基站，其特徵在於包括權利要求10-13中任一項所述的裝置。
15.一種集群業務處理裝置，其特徵在於，包括 接收模塊，用於接收用於對與基站基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息； 第一判斷模塊，用於判斷是否成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功；第二發送模塊，用於在所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功的情況下，向所述基站發送非確認信息。
16.根據權利要求15所述的裝置，其特徵在於，所述第一判斷模塊包括 第一判斷單元，用於判斷所述基站是否向所述UE發送了採用Group-RNTI標識和加擾的物理下行控制信道roccH，以及所述基站是否通過預定子幀通知所述UE所述roccH中是否存在所述GTCH的調度信息，其中，所述HXXH承載有所述調度信息； 第二判斷單元，用於在所述第一判斷單元的判斷結果為是的情況下，判斷根據採用Group-RNTI標識和加擾的所述TOCCH是否能夠接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的物理下行共享信道I3DSCH是否成功； 確定單元，用於在所述第二判斷單元的判斷結果為否的情況下，確定所述UE沒有成功接收到所述調度信息，和/或，根據所述調度信息解碼GTCH映射的所述H)SCH不成功。
17.一種用戶設備，其特徵在於包括權利要求15-16中任一項所述的裝置。
全文摘要
本發明提供了一種集群業務處理方法、裝置、基站及用戶設備，該方法包括基站生成用於對與一個或多個用戶設備UE基於長期演進LTE系統進行集群業務的集群業務信道GTCH資源進行調度的調度信息；基站將生成的該調度信息發送給一個或多個UE，通過本發明，解決了集群通信系統並不能滿足用戶業務需求，以及用戶體驗降低的問題，進而達到了滿足用戶基於LTE系統的集群業務需求，以及提高用戶體驗的效果。
文檔編號H04W72/04GK102892084SQ20121037516
公開日2013年1月23日 申請日期2012年9月28日 優先權日2012年9月28日
發明者李良斌, 謝忠時, 李毅, 黃志強, 餘西 申請人:中興通訊股份有限公司南京分公司