一種解決微信信令風(fēng)暴的基站側(cè)跨層信令優(yōu)化傳輸方案的制作方法
【技術(shù)領(lǐng)域】
[0001]本專利涉及電子信息領(lǐng)域中通信的傳輸技術(shù)優(yōu)化，具體來說，涉及一種對現(xiàn)有無線通信網(wǎng)絡(luò)中基站傳輸內(nèi)容的優(yōu)化，以解決大用戶數(shù)場景下信令負(fù)載問題。
【背景技術(shù)】
[0002]隨著無線通信系統(tǒng)的快速發(fā)展，越來越多的移動端應(yīng)用軟件得到廣泛的應(yīng)用，尤其是近些年來終端處理能力的大幅度提升，軟件的應(yīng)用呈現(xiàn)多樣化趨勢?？蛻舳塑浖梢岳靡苿泳W(wǎng)絡(luò)為用戶提供多種多樣的功能，諸如常見的移動端即時(shí)通信軟件QQ、微信等。這類即時(shí)通信軟件在位用戶提供實(shí)時(shí)的接入同時(shí)，由于必須和服務(wù)器交互以獲取用戶的在線或者離線狀態(tài)，有可能會使得網(wǎng)絡(luò)負(fù)載隨著用戶數(shù)量的增大而顯著提升，造成信令擁塞。即時(shí)通信軟件的在線狀態(tài)標(biāo)記信息需要占用系統(tǒng)的數(shù)據(jù)服務(wù)帶寬進(jìn)行傳輸，因此當(dāng)用戶數(shù)量較多時(shí)，軟件大量發(fā)送短數(shù)據(jù)信息，將使得網(wǎng)絡(luò)性能急劇下降。與此類似的，移動網(wǎng)絡(luò)中尋呼信號的特點(diǎn)類似于即時(shí)通信軟件的在線狀態(tài)標(biāo)記信號，但是尋呼信號使用的是專用控制信道(廣播信道)進(jìn)行數(shù)據(jù)傳輸，因此不會對數(shù)據(jù)傳輸帶來壓力。

【發(fā)明內(nèi)容】

[0003]為了評估即時(shí)通信軟件帶來的應(yīng)用層的信令負(fù)載，其信令傳輸流程必須進(jìn)行必要的討論，從而得出流程中可以優(yōu)化的部分，降低網(wǎng)絡(luò)的負(fù)載。
[0004]傳統(tǒng)的尋呼等信令主要用于探測用戶的在線狀態(tài)，由基站側(cè)主動發(fā)出。由于該信令內(nèi)容僅僅提供給網(wǎng)絡(luò)側(cè)進(jìn)行分析和存儲，因此使用專用的物理信道，使用專用的資源進(jìn)行傳輸。在專用物理信道中，信令不會占據(jù)數(shù)據(jù)傳輸?shù)膸捄凸β?，因此不會影響到用戶?cè)體現(xiàn)的網(wǎng)絡(luò)性能。以WCDMA系統(tǒng)為例，當(dāng)網(wǎng)絡(luò)側(cè)要確定某個(gè)移動終端在線或者離線與否時(shí)，基站側(cè)將發(fā)送尋呼(paging)信令來確定狀態(tài)。
[0005]圖1描述了 WCDMA系統(tǒng)中用戶在線和離線的兩種可能狀態(tài)流程。其中，無線網(wǎng)絡(luò)控制器(RNC)每隔180秒需要對用戶的在線或者離線狀態(tài)進(jìn)行刷新，因此該尋呼信令將在給定的時(shí)刻由基站側(cè)廣播給所轄用戶。首先，基站側(cè)將發(fā)送下行的尋呼信令，如果用戶當(dāng)前處于在線狀態(tài)，那么該用戶將在給定的時(shí)間段內(nèi)返回尋呼確認(rèn)ack信號，表明已經(jīng)收到尋呼請求，且當(dāng)前狀態(tài)為在線?；緜?cè)收到信息后會將該信息傳送給無線網(wǎng)絡(luò)控制器，并在移動用戶狀態(tài)寄存器中更新狀態(tài)。如果某個(gè)移動用戶處于離線狀態(tài)，系統(tǒng)的流程會有部分區(qū)另IJ。當(dāng)用戶處于無服務(wù)狀態(tài)等被動場景時(shí)無法回應(yīng)基站側(cè)的尋呼請求，最終會因?yàn)槌瑫r(shí)被標(biāo)記為離線狀態(tài)并在網(wǎng)絡(luò)端標(biāo)記。當(dāng)用戶需要關(guān)機(jī)等主動離開網(wǎng)絡(luò)時(shí)，用戶將響應(yīng)尋呼請求，并上報(bào)離線申請，最終完成狀態(tài)標(biāo)記。尋呼信令無需占據(jù)系統(tǒng)數(shù)據(jù)傳輸帶寬，因此尋呼信號對系統(tǒng)性能的影響幾乎可以忽略不計(jì)，即使用戶數(shù)量急劇增大，其對控制信道的影響也不會擴(kuò)散到數(shù)據(jù)信道。然而，來自即時(shí)通信軟件的心跳信號則需要占用數(shù)據(jù)信道帶寬，隨著用戶數(shù)量的增大，其性能會受到較大的影響。
[0006]圖2給出了即時(shí)通信軟件的在線或者離線狀態(tài)的判別方案。很明顯，應(yīng)用層是虛擬層且不具備傳輸實(shí)體，因此論文采用虛線代表了微信軟件的應(yīng)用層，而其余的實(shí)體層使用實(shí)線表示。在這種場景下，用戶在線狀態(tài)請求由騰訊服務(wù)器發(fā)出，在網(wǎng)絡(luò)側(cè)作為數(shù)據(jù)進(jìn)行傳輸，因此該信號是在數(shù)據(jù)信道傳輸?shù)男奶盘?。通常來說，這種狀態(tài)確認(rèn)信號僅僅包含4比特或更少的信息，在應(yīng)用軟件內(nèi)進(jìn)行內(nèi)容解析，但是卻需要消耗一整個(gè)數(shù)據(jù)幀來進(jìn)行傳輸和處理，當(dāng)用戶從基站側(cè)收到信號時(shí)，軟件將通過數(shù)據(jù)傳輸信道發(fā)送確認(rèn)的ack信息。當(dāng)用戶在線時(shí)，系統(tǒng)可以直接將信息傳輸至應(yīng)用層軟件，而當(dāng)用戶出現(xiàn)超時(shí)回復(fù)或者主動離線時(shí)，騰訊服務(wù)器將把該用戶標(biāo)記為離線狀態(tài)。
[0007]因此，控制信道的信令信息和軟件發(fā)起的在線狀態(tài)請求信息具有相類似的功能但是完全不同的資源占用方式。諸如尋呼等信令使用專用的控制信道進(jìn)行傳輸且基本不會影響用戶的性能；與此相反，心跳信號包含在數(shù)據(jù)傳輸中，且在應(yīng)用層起作用，因此底層傳輸并不知曉這是信令類的傳輸，而是僅僅把它當(dāng)成普通數(shù)據(jù)傳輸。當(dāng)用戶數(shù)量增加時(shí)，軟件發(fā)起的心跳信號將逐漸占用更多的數(shù)據(jù)帶寬和傳輸功率，從而極大的影響傳輸性能。
[0008]考慮到心跳信號占用系統(tǒng)資源，影響系統(tǒng)性能的特點(diǎn)，論文提出了一種可行的跨層數(shù)據(jù)共享方案來降低心跳信號對資源的占用。
[0009]無論是心跳信號還是尋呼這類的控制信令，其主要功能是標(biāo)記用戶的在線或者離線狀態(tài)。控制信令之所以不會顯著影響系統(tǒng)性能，是因?yàn)榭刂菩帕钣袑Ｓ玫目刂菩诺肋M(jìn)行傳輸，不會占用系統(tǒng)數(shù)據(jù)傳輸資源，而心跳信號無法做到這一點(diǎn)。
[0010]考慮到系統(tǒng)的跨層資源可共享，可以將心跳信號標(biāo)記的在線或者離線狀態(tài)由信令幀發(fā)送，并在基站端進(jìn)行跨層數(shù)據(jù)提取，這樣系統(tǒng)就可以有效地利用專用控制信道傳輸數(shù)據(jù)信息。僅僅需要的改進(jìn)是，基站端能夠識別和分離從控制信道傳輸?shù)陌浖诰€狀態(tài)標(biāo)記的信息。
[0011]如圖3所示，給出了論文所述的一種改進(jìn)型心跳信令傳輸流程。傳統(tǒng)場景下，移動用戶的心跳信號自用戶應(yīng)用層發(fā)出，通過數(shù)據(jù)信道經(jīng)基站發(fā)送至騰訊服務(wù)器，并在服務(wù)器端解析至應(yīng)用層，這一過程與傳輸其他的語音、文本等信號是一致的，因而這也是產(chǎn)生誤碼率升高的主要原因。改進(jìn)的流程主要是基于心跳信號的跨層共享設(shè)計(jì)，即心跳信號擁有和尋呼等信令類似的傳輸頻率、數(shù)據(jù)結(jié)構(gòu)以及功能，完全可以利用公共控制信道進(jìn)行傳輸。同樣的，心跳信號最初仍然在用戶端應(yīng)用軟件的應(yīng)用層產(chǎn)生，發(fā)送至物理層進(jìn)行傳輸。
[0012]這里我們引入一個(gè)標(biāo)記信號，所有應(yīng)用層產(chǎn)生的心跳信號在物理層將被分離出來。也就是說，物理層知曉這些信號屬于信令類型的數(shù)據(jù)信號，當(dāng)需要傳輸時(shí)，物理層按照信令的傳輸流程從公共控制信道進(jìn)行數(shù)據(jù)傳輸，并在基站側(cè)進(jìn)行解析?；緜?cè)根據(jù)物理層標(biāo)記將該信號從公共控制類信號解包，并重新將該信號封裝為具有源用戶ip地址和mac地址的數(shù)據(jù)包并從有線網(wǎng)(以太或者光纖主干網(wǎng))發(fā)送至騰訊公司服務(wù)器，最終在服務(wù)器端解析成心跳信號。這樣跨層數(shù)據(jù)共享和利用公共控制信道傳輸?shù)膬?yōu)勢在于:公共控制信道的資源不影響數(shù)據(jù)傳輸?shù)乃俾屎驼`碼率，只影響用戶的接入，且公共控制信道的預(yù)留資源豐富，完全有能力承載部分具有信令特點(diǎn)的數(shù)據(jù)信號傳輸，從而降低數(shù)據(jù)信道傳輸壓力，達(dá)到資源的最優(yōu)利用。
【主權(quán)項(xiàng)】
1.一種針對微信信令風(fēng)暴的協(xié)同處理流程:當(dāng)使用微信等即時(shí)通信軟件人數(shù)較多時(shí)，因軟件需要知曉用戶的在線狀態(tài)需要在用戶靜默時(shí)每隔30秒請求用戶的在線狀態(tài)，造成了大用戶數(shù)量時(shí)的信令負(fù)載；為了解決該信令風(fēng)暴問題，該專利特征在于: 基站側(cè)通過跨層信息共享知曉用戶發(fā)送和接收服務(wù)器端的在線請求信息； 基站側(cè)通過跨層信息共享將該種類信令通過公共控制信道發(fā)送和接收； 基站側(cè)通過跨層信息共享將信息重新組裝并發(fā)送至軟件服務(wù)器； 該處理流程不需要對微信服務(wù)器進(jìn)行任何操作，僅需要在基站側(cè)和用戶側(cè)進(jìn)行軟修改，用于識別位于應(yīng)用層的用戶在線狀態(tài)信息。2.根據(jù)權(quán)利要求1所述的基站側(cè)通過跨層信息共享分離出微信在線狀態(tài)信令，其特征是: 基站側(cè)通過光纖，同軸電纜，無線回程鏈路等方式從軟件服務(wù)器端得到的數(shù)據(jù)，通過跨層信息共享解析出在線狀態(tài)請求信令； 在線狀態(tài)請求信令經(jīng)優(yōu)化后通過公共控制信道發(fā)送和接收，節(jié)省系統(tǒng)數(shù)據(jù)帶寬資源。3.根據(jù)權(quán)利要求1所述的基站側(cè)通過跨層信息共享將微信通過專用控制信道發(fā)送的在線狀態(tài)信息分離，并重新組合，通過基站的高速數(shù)據(jù)鏈路發(fā)送至服務(wù)器端，其特征是: 基站側(cè)收到專用控制信道的信息后，通過解析信息標(biāo)識信號，將微信軟件的在線信息分離出來； 基站側(cè)將分離出來后的微信在線狀態(tài)匯報(bào)(狀態(tài)請求)信息重新組合，通過高速數(shù)據(jù)傳輸鏈路發(fā)送至微信服務(wù)器端。4.根據(jù)權(quán)利要求1所述的基站側(cè)通過跨層信息共享降低網(wǎng)絡(luò)用戶數(shù)量較大時(shí)，使用微信等即時(shí)通信軟件造成的信令風(fēng)暴的操作流程，其特征是: 步驟1:基站側(cè)通過跨層信息共享，解析出位于應(yīng)用層的微信服務(wù)器端向指定用戶發(fā)送的在線狀態(tài)請求信息； 步驟2:基站側(cè)將微信軟件的在線狀態(tài)請求信息加上信息標(biāo)識信號，通過專用控制信道發(fā)送至用戶； 步驟3:用戶側(cè)將微信軟件的在線狀態(tài)匯報(bào)信息加上信息標(biāo)識信號，通過專用控制信道發(fā)送至基站側(cè)； 步驟4:基站側(cè)將專用控制信道收到的信息解析至應(yīng)用層并重新封裝； 步驟5:基站側(cè)將重新封裝的信息通過高速網(wǎng)絡(luò)鏈路，如光纖、同軸電纜等發(fā)送至微信服務(wù)器端； 步驟6:微信服務(wù)器收到在線狀態(tài)信息，并更新用戶的在線狀態(tài)信息。
【專利摘要】本發(fā)明公開了一種應(yīng)用于蜂窩無線移動通信基站側(cè)的跨層信息共享和優(yōu)化方案，解決無線網(wǎng)絡(luò)中用戶基數(shù)較大場景下使用微信等即時(shí)通信軟件造成的信令風(fēng)暴問題。本發(fā)明通過以下技術(shù)方案實(shí)現(xiàn)該優(yōu)化：通過基站側(cè)的跨層信息共享技術(shù)，基站側(cè)將即時(shí)通信軟件的在線狀態(tài)請求信息以及軟件側(cè)的在線狀態(tài)匯報(bào)信息解析出來，通過專用控制信道資源發(fā)送，從而降低數(shù)據(jù)傳輸?shù)呢?fù)載。該方案的實(shí)現(xiàn)核心在于基站側(cè)的跨層數(shù)據(jù)共享和解析，即基站側(cè)將來自用戶和軟件服務(wù)器的信息解包至應(yīng)用層，將在線狀態(tài)確認(rèn)信息提取并通過專用控制信道發(fā)送，從而實(shí)現(xiàn)降低網(wǎng)絡(luò)負(fù)載，提高傳輸成功率的作用。
【IPC分類】H04W28/12
【公開號】CN105307213
【申請?zhí)枴緾N201510596158
【發(fā)明人】高原, 李漪, 周波, 敖洪, 周全, 褚劍
【申請人】高原, 周波, 敖洪, 周全, 褚劍, 李漪
【公開日】2016年2月3日
【申請日】2015年9月18日