W高級(jí)尋呼過程分析培訓(xùn)_第1頁
W高級(jí)尋呼過程分析培訓(xùn)_第2頁
W高級(jí)尋呼過程分析培訓(xùn)_第3頁
W高級(jí)尋呼過程分析培訓(xùn)_第4頁
W高級(jí)尋呼過程分析培訓(xùn)_第5頁
已閱讀5頁,還剩52頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

會(huì)計(jì)學(xué)1W高級(jí)尋呼過程分析培訓(xùn)前言

尋呼是接入過程中一個(gè)主要的行為,也是優(yōu)化接入過程性能的一個(gè)主要方面。本文檔概要介紹了尋呼的基本過程,在此基礎(chǔ)上對(duì)尋呼相關(guān)的關(guān)鍵參數(shù)、信令、性能等內(nèi)容進(jìn)行了分析,幫助使用者熟悉WCDMA的尋呼過程。第1頁/共57頁課程目標(biāo)尋呼的主要過程尋呼過程的消息尋呼性能分析學(xué)習(xí)完本課程,您將能夠熟悉:第2頁/共57頁課程內(nèi)容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第3頁/共57頁第一章尋呼的主要過程第一節(jié)尋呼的類型第二節(jié)尋呼流程第三節(jié)DRX過程第4頁/共57頁尋呼的類型PagingType1:應(yīng)用于UE處于idle、CELL_PCH、URA_PCH狀態(tài)時(shí)。PagingType2:應(yīng)用于UE處于CELL_FACH或者CELL_DCH狀態(tài)時(shí)。第5頁/共57頁尋呼的類型CN發(fā)起的尋呼:CN發(fā)起尋呼的目的是使CN能夠請(qǐng)求UTRAN聯(lián)系UE。尋呼過程在IU接口使用無連接的信令過程。CN通過發(fā)送尋呼消息觸發(fā)尋呼過程,UTRAN則將CN尋呼消息通過UU接口上的尋呼過程發(fā)送給UE,使得被尋呼的UE發(fā)起與CN的信令連接建立過程。UTRAN發(fā)起的尋呼:當(dāng)系統(tǒng)消息發(fā)生改變時(shí),UTRAN為了通知處在空閑模式、CELL_PCH和URA_PCH狀態(tài)下的UE進(jìn)行系統(tǒng)消息更新,會(huì)觸發(fā)尋呼過程。為了觸發(fā)處于CELL_PCH,URA_PCH狀態(tài)下的UE進(jìn)行狀態(tài)遷移,UTRAN會(huì)進(jìn)行一次尋呼流程,作為對(duì)該尋呼的一種應(yīng)答形式,UE會(huì)相應(yīng)的發(fā)起一次小區(qū)更新或URA更新過程。

第6頁/共57頁第一章尋呼的主要過程第一節(jié)尋呼的類型第二節(jié)尋呼流程第三節(jié)DRX過程第7頁/共57頁尋呼流程尋呼類型1CN發(fā)起的尋呼:如果IU接口的PAGING消息中帶有LAI或者RAI,RNC會(huì)向指定位置區(qū)或路由區(qū)的所有小區(qū)下發(fā)PAGINGTYPE1消息;如果沒有LAI或者RAI,RNC會(huì)向本RNC的所有小區(qū)下發(fā)PAGINGTYPE1消息。如下圖所示,CN在一個(gè)位置區(qū)LA中發(fā)起尋呼,LA分布在兩個(gè)RNC中。RNC收到尋呼消息后,根據(jù)LAI查找與其對(duì)應(yīng)的所有小區(qū),然后計(jì)算出尋呼時(shí)刻,尋呼時(shí)刻到來時(shí)在PCCH上向這些小區(qū)發(fā)送尋呼類型1消息。UTRAN發(fā)起的尋呼:當(dāng)UE處于CELL_PCH或URA_PCH狀態(tài)時(shí),如果UTRAN需要和UE進(jìn)行信息交互,包括信令和數(shù)據(jù),需要在PCCH上發(fā)送尋呼類型1來通知UE從CELL_PCH或URA_PCH遷移到CELL_FACH,UE通過小區(qū)更新的過程來完成狀態(tài)遷移。

第8頁/共57頁尋呼流程尋呼類型1第9頁/共57頁尋呼流程尋呼類型2如果UE處于CELL_DCH或者CELL_FACH狀態(tài),UTRAN會(huì)在DCCH上向被尋呼的UE發(fā)送尋呼類型2消息。第10頁/共57頁尋呼流程UE收到尋呼后的行為

UTRAN在同一尋呼時(shí)刻可以對(duì)多個(gè)UE進(jìn)行尋呼,每個(gè)被呼UE的信息包含在PAGINGTYPE1中的“pagingrecord”。若包含信息元素“BCCHmodificationinfo”,任何在空閑模式、CELL_PCH或URA_PCH狀態(tài)的UE應(yīng)重新讀取系統(tǒng)消息,不去理會(huì)“Pagingrecord”的內(nèi)容。其他:如果UE在空閑模式,UE將:

1、若信息元素"Usedpagingidentitypagingoriginator"為一個(gè)CN標(biāo)識(shí),則比較其中包含的CNIE“UE標(biāo)識(shí)類型”和所有其分配的CNUE標(biāo)識(shí);若找到一個(gè)相匹配,則指示尋呼接收;

2、否則,UE將忽略該尋呼記錄。如果UE在連接模式,UE將:

1、若信息元素"Usedpagingidentity"為UTRAN,并且這個(gè)U-RNTI和已分配給UE的U-RNTI相同: -如果包括可選信息元素“CNoriginatedpagetoconnectedmodeUE”,則UE指示尋呼接受; -如果不包括可選信息元素“CNoriginatedpagetoconnectedmodeUE”,UE執(zhí)行以“pagingresponse”為原因的小區(qū)更新過程;

2、若信息元素“Usedpagingidentity”不為UTRAN,UE忽略該尋呼記錄。第11頁/共57頁第一章尋呼的主要過程第一節(jié)尋呼的類型第二節(jié)尋呼流程第三節(jié)DRX過程第12頁/共57頁DRX過程PICH尋呼指示信道(PICH)是固定速率的物理信道(擴(kuò)頻因子為256),用于攜帶尋呼指示(PI)。PICH總是和PCH所映射的SCCPCH相關(guān)聯(lián)。下圖給出了PICH的幀結(jié)構(gòu)。一個(gè)長(zhǎng)度為10ms的PICH由300bit組成,其中288bit(b0,b1,……,b288)用于攜帶尋呼指示,剩余12個(gè)bit留作后用。第13頁/共57頁DRX過程N(yùn)umberofpagingindicatorsperframe(Np)Pq=1Pq=0Np=18{b16q,…,b16q+15}={1,1,…,1}{b16q,…,b16q+15}={0,0,…,0}Np=36{b8q,…,b8q+7}={1,1,…,1}{b8q,…,b8q+7}={0,0,…,0}Np=72{b4q,…,b4q+3}={1,1,…,1}{b4q,…,b4q+3}={0,0,…,0}Np=144{b2q,b2q+1}={1,1}{b2q,b2q+1}={0,0}每個(gè)PICH幀攜帶NP個(gè)尋呼指示,NP定義了PICH信道上每幀支持的最多尋呼指示數(shù),UE在小區(qū)系統(tǒng)消息中獲取NP的值。NP的取值為18,36,72,144,相當(dāng)于將288個(gè)bit分為NP個(gè)等份,每等份有288/NP個(gè)bits,每等份就是一個(gè)尋呼指示(PI)。MappingofpagingindicatorsPqtoPICHbits第14頁/共57頁DRX過程PICH和SCCPCH的關(guān)聯(lián)尋呼指示信道(PICH),用于攜帶尋呼指示(PI)。PCH承載于SCCPCH信道,其攜帶被尋呼的UE的具體信息。PICH總是和PCH所映射的SCCPCH相關(guān)聯(lián)。PICH無線幀的尾部比隨路的SCCPCH提前7680chips。PICH和SCCPCH的定時(shí)關(guān)系如下圖所示:第15頁/共57頁DRX過程UE采用非連續(xù)的方式偵聽PICH,監(jiān)視尋呼指示PI,如下圖所示UE要監(jiān)視每個(gè)尋呼周期中紅點(diǎn)所指示的幀(pagingoccasions),然后解碼該幀第q個(gè)PI,q的計(jì)算如下。第16頁/共57頁DRX過程DRX循環(huán)長(zhǎng)度和尋呼時(shí)刻UE在空閑模式下按一定的周期去解碼PICH,只有存在尋呼指示時(shí),才會(huì)去解碼隨路的SCCPCH信息,即不連續(xù)接收方式(DRX)??臻e模式下DRX尋呼周期的計(jì)算公式:

DRXcyclelength=(2^K)*PBPframes其中:K為IE“CNdomainspecificDRXcyclelengthcoefficient”,目前CS和PS的K值都是6;PBP為尋呼塊周期(主要用于TDD模式),F(xiàn)DD模式下,PBP=1。UE尋呼時(shí)刻的計(jì)算公式:

PagingOccasion(CELLSFN)={(IMSIdivM)mod(DRXcyclelengthdivPBP)}*PBP+n*DRXcyclelength+FrameOffset這里n=0,1,2……,只要計(jì)算出的PagingOccasion小于SFN的最大值4096,在FDD情況下FrameOffset=0,M是承載PCH的SCCPCH的個(gè)數(shù),通常為1。上述公式可以簡(jiǎn)化為:

SFN=IMSImod(2^K)+n*(2^K)

第17頁/共57頁DRX過程UE通過計(jì)算出自己的尋呼指示下標(biāo)P(PICH每幀的第q等份bits):其中PI=DRXindexmodNP=(IMSIdiv8192)modNP,SFN就是UE的尋呼時(shí)刻,為PICH開始出現(xiàn)時(shí)PCCPCH的SFN。根據(jù)以上公式,UE可知道自己PI的下標(biāo),這樣UE可以僅監(jiān)視PICH中的與自己關(guān)聯(lián)的bits,一旦發(fā)現(xiàn)它們被置為“1”時(shí),UE就知道自己被尋呼了。第18頁/共57頁DRX過程尋呼信道選擇系統(tǒng)信息塊類型5(SIB5)規(guī)定了空閑模式使用的尋呼信道。在一個(gè)小區(qū)內(nèi),可建立一個(gè)或幾個(gè)PCH,在系統(tǒng)信息中指出的每個(gè)SCCPCH可承載一個(gè)PCH,因此,對(duì)于每個(gè)規(guī)定的PCH都指出一個(gè)唯一對(duì)應(yīng)的PICH。如果在SIB5中規(guī)定了不只一個(gè)PCH和相關(guān)的PICH,UE將根據(jù)如下規(guī)則進(jìn)行選擇:UE將基于IMSI從SIB5列出的SCCPCH中選擇一個(gè)如下:

IndexofselectedSCCPCH=IMSImodK

這里,K等于列出承載一個(gè)PCH的SCCPCH的個(gè)數(shù),只承載一個(gè)FACH的SCCPCH將不計(jì)數(shù)。一般情況下,K值取1。目前一般實(shí)現(xiàn)的是一個(gè)小區(qū)配置一個(gè)PICH和一個(gè)SCCPCH,SCCPCH上承載兩個(gè)FACH和一個(gè)PCH。

第19頁/共57頁DRX過程DRX應(yīng)用舉例小區(qū)建立后,廣播的系統(tǒng)信息中,有關(guān)尋呼的參數(shù)設(shè)置為:IE“CNdomainspecificDRXcyclelengthcoefficient”:6IE“NumberofPIperframe”:36UE接收到這些信息后,計(jì)算出自己的尋呼時(shí)間、PI以及p值?,F(xiàn)有一個(gè)用戶,其IMSI為“448835805669362”,則該UE的計(jì)算結(jié)果如下:DRXcyclelength=64(2的6次方)CellSFN=“448835805669362”mod64+n*64=50+64*n(n=0,1,2,...)(假設(shè)此處n取值為3)PI=(448835805669362div8192)mod36=14q=(14+[((18*(242+[242/8]+[242/64]+[242/512]))mod144)*0.25])mod36=27從上面的計(jì)算可知,該小區(qū)PICH每幀攜帶36個(gè)尋呼指示,每個(gè)尋呼指示有288/36=8個(gè)bit組成,UE需要監(jiān)視每個(gè)PICH無線幀的bit216(27×8)~bit223,如果這些8個(gè)bit變成了"1",UE知道自己可能被尋呼了,要在SCCPCH上接收尋呼消息。第20頁/共57頁課程內(nèi)容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第21頁/共57頁第二章尋呼過程的消息第一節(jié)L3信令分析第二節(jié)L2信令分析第22頁/共57頁L3信令分析與尋呼相關(guān)的信令主要包括:Iu:PagingIub:“COMMONTRANSPORTCHANNELSETUPREQUEST”(配置PCH、PICH參數(shù))Uu:尋呼類型1、尋呼類型2、系統(tǒng)消息1、系統(tǒng)消息5。第23頁/共57頁IU口尋呼PagingCN如果需要和UE建立信令連接,就會(huì)在IU口發(fā)起尋呼過程。CN下發(fā)的PAGING消息包含以下信元:CNDomainIndicator:必選信元,表示尋呼消息來自CS還是PS域。PermanentNASUEIdentity:必選信元,被尋呼UE的IMSI。DRXCycleLengthCoefficient:可選信元,DRX循環(huán)長(zhǎng)度系數(shù)K,用于計(jì)算UE的DRX周期,如果該信元存在UTRAN就透?jìng)鹘oUE。UE可能會(huì)收到CS、PS、UTRAN配置的K值,UE取三者的最小值。TemporaryUEIdentity:可選信元,CN給UE分配的臨時(shí)標(biāo)識(shí)(TMSI或PTMSI),如果此信元不存在,UTRAN就使用IMSI進(jìn)行尋呼。PagingArea:CS尋呼使用位置區(qū)標(biāo)識(shí)LAI(MCC+MNC+LAC),PS的尋呼使用路由區(qū)標(biāo)識(shí)RAI(LAI+RAC)。PagingCause:發(fā)送尋呼消息的原因,詳細(xì)的尋呼原因可以參考3GPPTS25.413協(xié)議(主要是terminatingcall/signalling等)。NonSearchingIndicator:可選信元,CN指示RNC是否進(jìn)行協(xié)作尋呼。如果該信元不存在或者信元的值為“Searching”,并且UTRAN檢測(cè)到UE處于連接態(tài),UTRAN會(huì)在空口發(fā)起尋呼類型2,其它情況下發(fā)起尋呼類型1。第24頁/共57頁IU口尋呼IU口尋呼信令解析

第25頁/共57頁尋呼類型1尋呼類型1UTRAN可以通過尋呼分組在一個(gè)尋呼類型1消息中對(duì)多個(gè)UE進(jìn)行尋呼,尋呼類型1的信令解析如下圖所示。尋呼類型1包含以下信元:Pagingrecordlist:協(xié)議規(guī)定每個(gè)尋呼時(shí)刻最多可以尋呼8個(gè)UE,對(duì)應(yīng)8個(gè)UE尋呼記錄,每個(gè)尋呼記錄中包含尋呼的來源。如果是CN發(fā)起的尋呼,要給出CN的域標(biāo)識(shí)、UE的NAS層標(biāo)識(shí)、尋呼原因等信息;如果是UTRAN發(fā)起的尋呼,要給出AS層UE標(biāo)識(shí)URNTI。BCCHmodificationinfo:可選信元,使用valuetag標(biāo)識(shí)系統(tǒng)信息的改變。如果該信元存在,UE會(huì)忽略Pagingrecordlist,去讀系統(tǒng)消息。第26頁/共57頁尋呼類型1尋呼類型1第27頁/共57頁尋呼類型2尋呼類型2對(duì)處于CELL_DCH或CELL_FACH狀態(tài)的UE,UTRAN通過在DCCH上發(fā)送PAGINGTYPE2消息啟動(dòng)該過程。UTRAN可以在進(jìn)行其他過程時(shí)發(fā)送PAGINGTYPE2消息,同時(shí)那個(gè)過程的狀態(tài)不應(yīng)受到影響,除非另有說明。UTRAN應(yīng)將信息元素“Pagingcause”設(shè)為從上層接收的尋呼原因。如果沒有得到,UTRAN將其設(shè)為“Terminatingcauseunknown”。第28頁/共57頁公共傳輸信道建立請(qǐng)求COMMONTRANSPORTCHANNELSETUPREQUEST

(IUB)RNC通過IUB口信令“公共傳輸信道建立請(qǐng)求”來通知NODEBPCH傳輸信道參數(shù)和PICH的相關(guān)參數(shù)。從下圖可以看出,PCH的兩種傳輸塊格式(0x240,1x240),功率相對(duì)PCPICH大2個(gè)dB;PICH的NP值為36,功率比PCPICH小3個(gè)dB。第29頁/共57頁公共傳輸信道建立請(qǐng)求公共傳輸信道建立請(qǐng)求(IUB)第30頁/共57頁系統(tǒng)消息1系統(tǒng)消息1UTRAN通過系統(tǒng)消息1通知UEDRX循環(huán)周期系數(shù),如下圖所示,CS、PS的DRX循環(huán)周期系數(shù)都是8。第31頁/共57頁系統(tǒng)消息5系統(tǒng)消息5UE通過讀系統(tǒng)消息5得到PCH的傳輸格式和PICH的NP值。

第32頁/共57頁第二章尋呼過程的消息第一節(jié)L3信令分析第二節(jié)L2信令分析第33頁/共57頁L2信令分析L2信令分析第34頁/共57頁L2信令分析L2信令分析從上圖可以看出PCCH、MACC、PCHFP、SCCPCH間的映射關(guān)系,PCCH在RLC層采用TM模式,由MACC進(jìn)行尋呼分組的調(diào)度。PCH的相關(guān)特性在PCHFP幀中得到體現(xiàn),PCH數(shù)據(jù)幀包括尋呼指示信息和尋呼消息。為了尋呼一個(gè)UE,兩個(gè)連續(xù)PCH數(shù)據(jù)幀用連續(xù)CFN發(fā)送,第一幀包含尋呼指示信息,第二幀包括尋呼消息。對(duì)于NODEB來說,除了NP通過公共傳輸信道建立獲得,其它參數(shù)都體現(xiàn)在高層下發(fā)的PCHFP幀中,PI包含在PIbitmap中,DRXCyclelength是由具有相同的PI指示的PCHFP的時(shí)間間隔決定,尋呼時(shí)刻可以由PCHFP中的CFN計(jì)算得到。PCHFP幀結(jié)構(gòu)如下圖所示。第35頁/共57頁L2信令分析PCHFP結(jié)構(gòu)第36頁/共57頁L2信令分析其中數(shù)據(jù)幀中的各單元描述如下:頭部CRC:循環(huán)容余多項(xiàng)式是按一個(gè)數(shù)據(jù)幀的頭用多項(xiàng)式(X^7+X^6+X^2+1)來計(jì)算的。CRC的計(jì)算應(yīng)包括頭中的所有比特。值范圍:{0-127},字段長(zhǎng)度:7個(gè)比特。幀類型:描述它是一個(gè)控制幀還是數(shù)據(jù)幀。值范圍:{0=數(shù)據(jù),1=控制},字段長(zhǎng)度:1個(gè)比特。連接幀號(hào)(CFN):指示在上行鏈路上接收或?qū)⒁谙滦墟溌飞习l(fā)送的第一個(gè)數(shù)據(jù)是哪一個(gè)無線幀。值范圍和字段長(zhǎng)度取決于CFN所用的傳送信道。值范圍(PCH):{0-4095},字段長(zhǎng)度(PCH):12個(gè)比特;其它傳輸信道的CFN范圍(0-255)。傳輸格式指示:TFI是用于傳送一個(gè)TTI的傳送格式的標(biāo)識(shí)號(hào)。值范圍:{0-31},字段長(zhǎng)度:5個(gè)比特。第37頁/共57頁L2信令分析傳輸塊:傳輸塊為一個(gè)要傳送的或通過無線接口已接收的數(shù)據(jù)塊。TFI指示的傳輸格式描述了傳輸塊長(zhǎng)度和傳輸塊集合大小。凈荷CRC:循環(huán)容余多項(xiàng)式是按一個(gè)數(shù)據(jù)幀的凈荷用多項(xiàng)式(X^16+X^15+X^2+1)來計(jì)算的。CRC的計(jì)算應(yīng)包括數(shù)據(jù)幀的凈荷中的所有比特,字段長(zhǎng)度:16個(gè)比特。尋呼指示(PI):描述凈荷中是否出現(xiàn)PIBitmap。值范圍:{0=凈荷中無PI-Bitmap,1=凈荷中有PI-bitmap},字段長(zhǎng)度:1個(gè)比特。尋呼指示比特映射(PI-bitmap):尋呼指示PI0..PIN-1的bitmap。第一個(gè)字節(jié)的Bit7包含PI0,第一個(gè)字節(jié)的Bit6包含PI1,,...,第二個(gè)字節(jié)的Bit7包含PI8,并一直這樣下去。值范圍:{18,36,72或144尋呼指示}。字段長(zhǎng)度:3,5,9或18字節(jié)。如果PI-bitmap為1,標(biāo)識(shí)監(jiān)聽該尋呼指示位的手機(jī)被尋呼。第38頁/共57頁課程內(nèi)容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第39頁/共57頁第三章尋呼過程的性能第一節(jié)尋呼調(diào)度第二節(jié)尋呼參數(shù)分析第三節(jié)尋呼話統(tǒng)與告警第四節(jié)尋呼異常情況第40頁/共57頁尋呼調(diào)度尋呼調(diào)度在MACC進(jìn)行,主要?jiǎng)幼鳎篟NC的L3接到CN來的尋呼消息后,判斷如果系統(tǒng)沒有過載就將尋呼消息發(fā)給MACC,如果系統(tǒng)處于過載狀態(tài)就丟棄尋呼消息。MACC收到上層發(fā)來的尋呼消息后,計(jì)算出尋呼時(shí)刻,在離當(dāng)前CFN最近的一個(gè)尋呼周期的對(duì)應(yīng)位置將尋呼記錄保存下來,對(duì)于每個(gè)尋呼時(shí)刻MACC最多保存8個(gè)尋呼記錄,如果超過8個(gè)就會(huì)丟棄。在每個(gè)尋呼時(shí)刻到來時(shí),MACC對(duì)該尋呼時(shí)刻對(duì)應(yīng)的尋呼記錄進(jìn)行編碼后下發(fā)給NODEB,然后清除尋呼記錄,NODEB在小區(qū)尋呼信道下發(fā)。如果系統(tǒng)消息更新引起的尋呼,MACC立即編碼下發(fā),并清除所有的尋呼記錄。第41頁/共57頁尋呼調(diào)度PCH容量:目前MACC支持的PCH的傳輸塊為240bit,每幀支持的編碼后的尋呼消息不能超過240bit。根據(jù)尋呼類型1的信元結(jié)構(gòu)和ASN.1PER編碼規(guī)則,如果尋呼消息的UE標(biāo)識(shí)時(shí)IMSI,每個(gè)尋呼時(shí)刻最多支持3個(gè)UE,如果UE標(biāo)識(shí)是TMSI或者PTMSI最多支持5個(gè)UE。硬件處理能力問題:以目前PCH的編碼方式,一個(gè)尋呼幀尋呼的UE的個(gè)數(shù)還不能達(dá)到協(xié)議值8,如果在同一尋呼時(shí)刻尋呼UE的個(gè)數(shù)超過系統(tǒng)的處理能力,就會(huì)造成尋呼丟失,造成呼損的情況。根據(jù)尋呼時(shí)刻的計(jì)算方式,在配置IMSI時(shí)要進(jìn)行詳細(xì)規(guī)劃,保證每個(gè)UE的尋呼時(shí)刻均勻分布在一個(gè)尋呼周期內(nèi)每個(gè)幀上。網(wǎng)絡(luò)可以采取重發(fā)尋呼來提高UE的尋呼成功率。CN在尋呼定時(shí)器超時(shí)后在IU口重發(fā)尋呼消息,UTRAN也可以在MACC調(diào)度時(shí)重發(fā),表現(xiàn)在不同的尋呼周期內(nèi)重發(fā)。第42頁/共57頁第三章尋呼過程的性能第一節(jié)尋呼調(diào)度第二節(jié)尋呼參數(shù)分析第三節(jié)尋呼話統(tǒng)與告警第四節(jié)尋呼異常情況第43頁/共57頁尋呼參數(shù)分析DRX尋呼周期系數(shù)DRX尋呼周期系數(shù)K值決定了DRX周期長(zhǎng)度,K值越大,DRX周期就越長(zhǎng),UE功耗會(huì)降低,但是UE尋呼周期變長(zhǎng);如果K值過小,尋呼周期變小,UE處理尋呼開銷和功耗都會(huì)增加。協(xié)議值給出范圍2~12,目前我司取值6,尋呼周期為0.64秒。UE的DRX尋呼周期系數(shù)有三個(gè)來源:系統(tǒng)消息、CN的尋呼消息、UTRAN的Uu口信令,并且CS、PS的處理方式也不一樣。對(duì)于PS域,DRX尋呼周期系數(shù)由UE和SGSN通過NAS層消息(attach過程)協(xié)商,不管UE處于IDLE或者是連接狀態(tài)都以協(xié)商數(shù)據(jù)為準(zhǔn),如果協(xié)商失敗則使用CS域的尋呼系數(shù)。對(duì)于CS域,如果UE在IDLE狀態(tài)下,DRX尋呼周期系數(shù)使用系統(tǒng)消息、CN的尋呼消息中的最小值;如果UE在連接狀態(tài),DRX尋呼周期系數(shù)使用系統(tǒng)消息、CN的尋呼消息、UTRAN的UU口信令中的最小值。第44頁/共57頁尋呼參數(shù)分析DRX尋呼周期系數(shù)(二)

RNC有兩條MML命令可以修改DRX尋呼周期系數(shù):1、SETFRC修改UTRAN的DRX尋呼周期系數(shù)(“DRXCYCLELENCOEF”),通過如下信令通知UE:UU_CELL_UPDATE_CONFIRM、UU_URA_UPDATE_CONFIRM、UU_PH_CH_RECFG、UU_TR_CH_RECFG、UU_RB_SETUP、UU_RB_REL、UU_RB_RECFG2、MODCNDOMAIN修改CS、PS的DRX尋呼周期系數(shù),修改后會(huì)發(fā)尋呼類型1通知UE讀更新后的系統(tǒng)消息(inIdleMode)。

第45頁/共57頁尋呼參數(shù)分析NP值Np是物理信道PICH在一幀中下發(fā)的PI尋呼指示數(shù),取值范圍在(18,36,72,144),該參數(shù)在系統(tǒng)消息5中通過“NumberofPIperframe”指示。UE會(huì)在確定的尋呼時(shí)機(jī)接收PICH發(fā)送的PI幀,只有相應(yīng)的PI指示有效,UE才會(huì)去解調(diào)后續(xù)的S-CCPCH幀。Np參數(shù)將所有的UE分成了Np組,每一個(gè)組中所有的UE使用同一個(gè)PI。Np的取值對(duì)網(wǎng)絡(luò)的影響:Np的值設(shè)置過小,則每組中對(duì)應(yīng)的UE數(shù)目較多,對(duì)每個(gè)UE而言,PI指示出現(xiàn)的概率增大,被喚醒的次數(shù)越多;Np值設(shè)置過大,則每組中對(duì)應(yīng)的UE數(shù)目較少,對(duì)每個(gè)IMSI而言,PI指示出現(xiàn)的概率也較小,被喚醒的次數(shù)也較少;Np越大,對(duì)UE的PICH解調(diào)性能要求越高。該參數(shù)通過ADDPICH命令設(shè)置(“PICHMODE”)。

第46頁/共57頁尋呼參數(shù)分析尋呼重發(fā)次數(shù)和時(shí)間間隔為了提高尋呼的成功率,CN和RNC都會(huì)重發(fā)尋呼消息。但是尋呼重發(fā)會(huì)造成尋呼量的增加,特別是在空中接口公共下行信道擁塞的情況下,大大浪費(fèi)下行信道資源,造成新的尋呼消息不能及時(shí)下發(fā)。為了兼顧尋呼成功率和尋呼效率,CN尋呼重發(fā)次數(shù)和時(shí)間間隔要和UTRAN的重發(fā)結(jié)合起來考慮。目前我司的實(shí)現(xiàn)是RNC重發(fā)一次尋呼類型1消息,前后兩次的間隔是一個(gè)尋呼周期,DRX循環(huán)周期系數(shù)取值6,也就是間隔640ms。CN最多支持4次尋呼重發(fā),即CN支持尋呼消息的5次發(fā)送。CN尋呼重發(fā)時(shí)間間隔可以設(shè)由CN通過軟參設(shè)置。設(shè)置CN尋呼重發(fā)次數(shù)和時(shí)間間隔的命令為MODPGCTRL;設(shè)置RNC尋呼重發(fā)次數(shù)的命令為SETWFMRCFGDATA(“MACCPAGEREPEAT”)。第47頁/共57頁尋呼參數(shù)分析尋呼重發(fā)次數(shù)和時(shí)間間隔(二)在CN重發(fā)1次的情況下,CN尋呼重發(fā)的時(shí)間間隔可以按以下考慮:如果UTRAN不重發(fā),CN重發(fā)時(shí)間間隔應(yīng)該大于一個(gè)DRX周期(640ms),可以取1s。從以上的尋呼調(diào)度可以看出,當(dāng)一個(gè)尋呼消息從CN發(fā)到UTRAN,UTRAN計(jì)算出的尋呼時(shí)刻CFN離當(dāng)前PCHCFN的最大時(shí)間間隔是一個(gè)DRX周期(640ms),如果在這個(gè)時(shí)間間隔內(nèi)CN再發(fā)一個(gè)尋呼消息過來,上一個(gè)尋呼消息還沒有發(fā)出,這樣會(huì)造成不必要的信道帶寬浪費(fèi)。如果UTRAN重發(fā)1次,CN重發(fā)時(shí)間應(yīng)該大于2個(gè)DRX周期。遵循一個(gè)原則,CN應(yīng)該等到UTRAN完成上一條尋呼消息的發(fā)送和重發(fā)后再重發(fā)下一條尋呼消息。為了保證這個(gè)原則,可以同時(shí)調(diào)整CN的重發(fā)次數(shù)、重發(fā)時(shí)間間隔、UTRAN重發(fā)次數(shù)、DRX尋呼周期等參數(shù)使其滿足這個(gè)關(guān)系原則。

第48頁/共57頁第三章尋呼過程的性能第一節(jié)尋呼調(diào)度第二節(jié)尋呼參數(shù)分析第三節(jié)尋呼話統(tǒng)與告警第四節(jié)尋呼異常情況第49頁/共57頁尋呼話統(tǒng)與告警尋呼話統(tǒng)RNC的尋呼話統(tǒng)指標(biāo)如下表所示。其中“CN_PAGE_IDLE_UE_SUCC_RATE”和“UTRAN_PAGE1_SUCC_RATE”兩個(gè)主要指標(biāo)表征了尋呼的性能。在CN側(cè)也可以統(tǒng)計(jì)尋呼的成功率、第一次/第二次尋呼的成功率等。話統(tǒng)指標(biāo)名稱話統(tǒng)指標(biāo)含義話統(tǒng)指標(biāo)標(biāo)準(zhǔn)測(cè)量點(diǎn)CN_PAGE_REQ統(tǒng)計(jì)IU接口尋呼的次數(shù)收到CN發(fā)起的PAGING消息CN_PAGE_IDLE_UE_REQ統(tǒng)計(jì)IU接口尋呼空閑用戶的次數(shù)收到CN發(fā)起的PAGING消息,且被尋呼的UE當(dāng)前為空閑態(tài)CN_PAGE_IDLE_UE_SUCC統(tǒng)計(jì)尋呼空閑用戶成功的次數(shù)收到UE的RRC連接請(qǐng)求消息,且請(qǐng)求原因?yàn)楸唤蓄愒颍纭癟erminatingConversationalCall”UTRAN

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論