 |
善于提問(wèn)，勤于回答，你也是專家
|
 |
問(wèn)題已開(kāi)啟
(普通問(wèn)題)
尋呼是建立在RRC連接請(qǐng)求之前嗎�。�
什么時(shí)候是尋呼type1什么時(shí)候是type2
提問(wèn)者:
• RRC重建占比如何提升 2020-08-18
• NR中，RRC_inactive狀態(tài)下，GNodeB是否有UE的上下文？就像下面的選擇題，總感覺(jué)答案不對(duì) 2020-06-16
• lteRRCradiolinkfailure 2020-06-08
• UE無(wú)應(yīng)答導(dǎo)致RRC建立失敗？ 2019-12-10
• AS和NAS分別是接入層和非接入層？各自的作用是什么？RRC是NAS的子層嗎？它又發(fā)揮了什么樣的作用？ 2019-10-21
• UE無(wú)應(yīng)答導(dǎo)致RRC建立失敗 2019-08-07
• 關(guān)于無(wú)線鏈路失�。�RRCRadioLinkFailure）誰(shuí)來(lái)解釋一下？ 2019-05-30
• 關(guān)于切換失敗的RRC連接重配消息 2019-05-19
• NR中，RRC_inactive狀態(tài)下，GNodeB是否有UE的上下文？就像下面的選擇題，總感覺(jué)答案不對(duì) 2020-06-16
• lteRRCradiolinkfailure 2020-06-08
• UE無(wú)應(yīng)答導(dǎo)致RRC建立失敗？ 2019-12-10
• AS和NAS分別是接入層和非接入層？各自的作用是什么？RRC是NAS的子層嗎？它又發(fā)揮了什么樣的作用？ 2019-10-21
• UE無(wú)應(yīng)答導(dǎo)致RRC建立失敗 2019-08-07
• 關(guān)于無(wú)線鏈路失�。�RRCRadioLinkFailure）誰(shuí)來(lái)解釋一下？ 2019-05-30
• 關(guān)于切換失敗的RRC連接重配消息 2019-05-19
問(wèn)題答案
( 4 )
是這樣的，答：
Type1/2/3是用來(lái)提高空口資源的效率的。
具體解釋如下：
首先，尋呼要通過(guò)PCH信道發(fā)送。PCH與AGCH共享CCCH的9個(gè)Block（9個(gè)，是指BCCH與SDCCH非combination得情況。如果是combine的，是3個(gè)）。對(duì)于GSM的51復(fù)幀結(jié)構(gòu)來(lái)說(shuō)， 9個(gè)block的長(zhǎng)度約為235ms。假設(shè)其中為AGCH預(yù)留2個(gè)block，那么用于發(fā)送尋呼的block為9-2=7個(gè)block。即在小區(qū)配置一個(gè)CCCH的情況下，每秒有(1000/235*7)=29次機(jī)會(huì)發(fā)送尋呼消息。假設(shè)MSC以每秒100個(gè)的速度尋呼手機(jī)，以Type1的方式，空口是無(wú)法完成的。為了提高空口效率，我們就希望一個(gè)消息能盡可能多地尋呼手機(jī)。
GSM每時(shí)隙信息比特?cái)?shù)為114bits，每個(gè)PCH block由4個(gè)時(shí)隙組成，即可發(fā)送57byte的數(shù)據(jù)，因此規(guī)范定義了
type1, 2個(gè)IMSI（或TMSI）
type2, 3個(gè)TMSI（或2個(gè)TMSI+1個(gè)IMSI）
type3, 4個(gè)TMSI的尋呼發(fā)送方式。這樣空口就提高了尋呼發(fā)送的效率。例如type3的方式下可每秒尋呼>110個(gè)手機(jī)
Type1/2/3是用來(lái)提高空口資源的效率的。
具體解釋如下：
首先，尋呼要通過(guò)PCH信道發(fā)送。PCH與AGCH共享CCCH的9個(gè)Block（9個(gè)，是指BCCH與SDCCH非combination得情況。如果是combine的，是3個(gè)）。對(duì)于GSM的51復(fù)幀結(jié)構(gòu)來(lái)說(shuō)， 9個(gè)block的長(zhǎng)度約為235ms。假設(shè)其中為AGCH預(yù)留2個(gè)block，那么用于發(fā)送尋呼的block為9-2=7個(gè)block。即在小區(qū)配置一個(gè)CCCH的情況下，每秒有(1000/235*7)=29次機(jī)會(huì)發(fā)送尋呼消息。假設(shè)MSC以每秒100個(gè)的速度尋呼手機(jī)，以Type1的方式，空口是無(wú)法完成的。為了提高空口效率，我們就希望一個(gè)消息能盡可能多地尋呼手機(jī)。
GSM每時(shí)隙信息比特?cái)?shù)為114bits，每個(gè)PCH block由4個(gè)時(shí)隙組成，即可發(fā)送57byte的數(shù)據(jù)，因此規(guī)范定義了
type1, 2個(gè)IMSI（或TMSI）
type2, 3個(gè)TMSI（或2個(gè)TMSI+1個(gè)IMSI）
type3, 4個(gè)TMSI的尋呼發(fā)送方式。這樣空口就提高了尋呼發(fā)送的效率。例如type3的方式下可每秒尋呼>110個(gè)手機(jī)
回答者：
xhy1331
回答時(shí)間：2011-10-10 16:33
17
17
被叫為空閑模式時(shí)為Paging type1，被叫為專用模式時(shí)為Paging type2
好像是這樣的，求確認(rèn)。
好像是這樣的，求確認(rèn)。
回答者：
zh695042631
回答時(shí)間：2011-10-10 17:11
26
19
type1, 2個(gè)IMSI（或TMSI）
type2, 3個(gè)TMSI（或2個(gè)TMSI+1個(gè)IMSI）
type3, 4個(gè)TMSI的尋呼發(fā)送方式。
type2, 3個(gè)TMSI（或2個(gè)TMSI+1個(gè)IMSI）
type3, 4個(gè)TMSI的尋呼發(fā)送方式。
回答者：
lbblbblbb
回答時(shí)間：2011-10-10 17:14
29
20
從MSC（或從A口）的角度來(lái)看，尋呼是一個(gè)MS沒(méi)錯(cuò)。（如08.08中定義的Paging，只帶一個(gè)MS下來(lái)）。
但是你提到的Paging Request是04.08中定義的，是從空口的角度來(lái)看的�？偟膩�(lái)說(shuō)，Type1/2/3是用來(lái)提高空口資源的效率的。具體解釋如下：
首先，尋呼要通過(guò)PCH信道發(fā)送。PCH與AGCH共享CCCH的9個(gè)Block（9個(gè)，是指BCCH與SDCCH非combination得情況。如果是combine的，是3個(gè)）。對(duì)于GSM的51復(fù)幀結(jié)構(gòu)來(lái)說(shuō)， 9個(gè)block的長(zhǎng)度約為235ms。假設(shè)其中為AGCH預(yù)留2個(gè)block，那么用于發(fā)送尋呼的block為9-2=7個(gè)block。即在小區(qū)配置一個(gè)CCCH的情況下，每秒有(1000/235*7)=29次機(jī)會(huì)發(fā)送尋呼消息。假設(shè)MSC以每秒100個(gè)的速度尋呼手機(jī)，以Type1的方式，空口是無(wú)法完成的。為了提高空口效率，我們就希望一個(gè)消息能盡可能多地尋呼手機(jī)。
GSM每時(shí)隙信息比特?cái)?shù)為114bits，每個(gè)PCH block由4個(gè)時(shí)隙組成，即可發(fā)送57byte的數(shù)據(jù)，因此規(guī)范定義了
type1, 2個(gè)IMSI（或TMSI）
type2, 3個(gè)TMSI（或2個(gè)TMSI+1個(gè)IMSI）
type3, 4個(gè)TMSI的尋呼發(fā)送方式。這樣空口就提高了尋呼發(fā)送的效率。例如type3的方式下可每秒尋呼>110個(gè)手機(jī)。（當(dāng)然如果MSC側(cè)以更高的速率發(fā)送Paging，需要增加CCCH的數(shù)量，或者減小LAC區(qū)的范圍了）。
另外，需要注意的是，當(dāng)一個(gè)Page Request里尋呼多個(gè)手機(jī)時(shí)，這些手機(jī)應(yīng)當(dāng)是同一尋呼組的。關(guān)于尋呼組的定義請(qǐng)參考3gpp的05.02。
尋呼組可作為尋呼信道(PCH)用來(lái)廣播尋呼請(qǐng)求，同時(shí)也可作為AGCH用來(lái)回應(yīng)手機(jī)的接入請(qǐng)求，即分配SDCCH｡操作上，可將數(shù)個(gè)復(fù)幀組合在一起，形成一個(gè)尋呼周期，增加小區(qū)內(nèi)的尋呼組數(shù)量｡手機(jī)會(huì)周期性地監(jiān)聽(tīng)所屬的尋呼組，于是當(dāng)手機(jī)作被叫時(shí)，會(huì)監(jiān)測(cè)到基站發(fā)送的尋呼請(qǐng)求，并做出回應(yīng)｡
尋呼組設(shè)置較多意味著手機(jī)在監(jiān)測(cè)到正確的尋呼組之前需要等較長(zhǎng)時(shí)間，這樣會(huì)增加尋呼的時(shí)間｡尋呼組設(shè)置較少會(huì)由于手機(jī)較為頻繁地接聽(tīng)尋呼組而縮短呼叫建立時(shí)長(zhǎng)，缺點(diǎn)是手機(jī)會(huì)很費(fèi)電｡一個(gè)小區(qū)尋呼組的數(shù)量可以通過(guò)以下2個(gè)參數(shù)來(lái)調(diào)整:
23byte，為46位HEX，即184bits信息量
TMSI：8位HEX
IMSI:15位BCD碼
根據(jù)TEMS的層三消息，個(gè)人認(rèn)為：4*8+6(頭BITS，用來(lái)標(biāo)識(shí)TMSI或IMSI+6(尾Bits）＝44<46
Paging Type 1：UE和RAN沒(méi)有RRC連接（在Idle模式）或者在CELL_PCH or URA_PCH狀態(tài)時(shí)，使用PCCH信道進(jìn)行尋呼，Type1尋呼消息可以針對(duì)多個(gè)UE；
Paging Type2：UE和RAN有RRC連接，且在CELL_DCH or CELL_FACH狀態(tài)時(shí)，在DCCH 信道AM RLC模式進(jìn)行尋呼，Type2尋呼消息是針對(duì)單個(gè)UE的，也稱為UE專有尋呼。
采用paging type1還是paging type2由RNC決定。
回答者：
OscarDon
回答時(shí)間：2011-10-10 23:34
20
20
OscarDon 2011-10-10 23:35
RNC在處理CN的尋呼消息時(shí)，根據(jù)判斷UE是否存在尋呼域之外的其它CN域信令連接，以及UE所處的模式和狀態(tài)，區(qū)分兩種類型的尋呼：Paging Type 1和Paging Type 2.
如果被尋呼的UE不存在其它的CN域信令連接，則UTRAN通過(guò)PCCH信道下發(fā)送Paging Type 1（第一類尋呼消息\
如果被尋呼的UE存在其它的CN域信令連接，且該UE處于CELL_PCH或者URA_PCH狀態(tài)，則UTRAN通過(guò)PCCH信道下發(fā)送Paging Type 1（第一類尋呼消息）；
如果被尋呼的UE已經(jīng)存在其它的CN域信令連接，且被尋呼的UE處于CELL_DCH或者CELL_FACH狀態(tài)，則UTRAN通過(guò)已經(jīng)存在連接的DCCH信道下發(fā)送Paging Type 2（第二類尋呼消息）。對(duì)于這種通過(guò)DCCH信道發(fā)送第二類尋呼消息的過(guò)程，也叫做專用尋呼過(guò)程。UE接收并讀取Paging Type 2中的內(nèi)容，并把尋呼原因及尋呼記錄種類標(biāo)識(shí)等信息上報(bào)給本側(cè)非接入層后結(jié)束尋呼過(guò)程，不影響UE側(cè)正在進(jìn)行的其它RRC進(jìn)程。
如果網(wǎng)絡(luò)要尋呼處于空閑狀態(tài)、CELL_PCH或者URA_PCH狀態(tài)的UE，首先由CN 通過(guò)Iu接口調(diào)用RANAP 消息 Paging發(fā)送給RNC，在特定區(qū)域（包括一個(gè)或多個(gè)RNC）內(nèi)尋呼某個(gè)UE。為了增加UE接收到尋呼的機(jī)會(huì)，UTRAN對(duì)一個(gè)尋呼消息會(huì)進(jìn)行多次重復(fù)發(fā)送，重復(fù)次數(shù)由系統(tǒng)設(shè)定，網(wǎng)優(yōu)不可見(jiàn)。另外，UTRAN通過(guò)在一個(gè)PAGING TYPE 1消息中為每個(gè)UE設(shè)置一個(gè)PAGING RECORD來(lái)實(shí)現(xiàn)在同一個(gè)尋呼時(shí)機(jī)同時(shí)尋呼多個(gè)UE。
RNC收到尋呼請(qǐng)求后，在PCCH上向UE發(fā)起尋呼類型1消息來(lái)尋呼特定UE。PCCH對(duì)應(yīng)的傳輸信道是PCH。通常PCH被分成一個(gè)個(gè)PCH 塊，以實(shí)現(xiàn)終端對(duì)尋呼消息的非連續(xù)接收（DRX）。最后UE通過(guò)Uu口檢測(cè)到從RNC來(lái)的對(duì)自己的尋呼消息PAGING TYPE 1，則發(fā)起RRC信令連接建立過(guò)程。
OscarDon 2011-10-10 23:36
• 中郵建技術(shù)有限公司
聘：成都移動(dòng)后臺(tái)高級(jí)
需求人數(shù)：1 人 地點(diǎn)：成都市
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：浙江網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：8 人 地點(diǎn)：寧波市,舟山市,湖州市,紹興市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：高速/高架優(yōu)化工程師
需求人數(shù)：3 人 地點(diǎn)：上海市
• 重慶信科通信工程有限公司 聘：后臺(tái)優(yōu)化
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 廣州瀚信通信科技股份有限公司 聘：項(xiàng)目經(jīng)理（廣東）
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 陜西瑞達(dá)灃通信技術(shù)有限公司 聘：華為光網(wǎng)絡(luò)工程師
需求人數(shù)：8 人 地點(diǎn)：新疆
• 西安中興精誠(chéng)通訊有限公司 聘：重慶萬(wàn)涪黔區(qū)域網(wǎng)優(yōu)前臺(tái)
需求人數(shù)：3 人 地點(diǎn)：重慶市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長(zhǎng)沙市,永州市,郴州市,衡陽(yáng)市
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 上海瑞禾通訊技術(shù)有限公司 聘：廣州中高級(jí)工程師
需求人數(shù)：3 人 地點(diǎn)：廣州市
需求人數(shù)：1 人 地點(diǎn)：成都市
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：浙江網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：8 人 地點(diǎn)：寧波市,舟山市,湖州市,紹興市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：高速/高架優(yōu)化工程師
需求人數(shù)：3 人 地點(diǎn)：上海市
• 重慶信科通信工程有限公司 聘：后臺(tái)優(yōu)化
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 廣州瀚信通信科技股份有限公司 聘：項(xiàng)目經(jīng)理（廣東）
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 陜西瑞達(dá)灃通信技術(shù)有限公司 聘：華為光網(wǎng)絡(luò)工程師
需求人數(shù)：8 人 地點(diǎn)：新疆
• 西安中興精誠(chéng)通訊有限公司 聘：重慶萬(wàn)涪黔區(qū)域網(wǎng)優(yōu)前臺(tái)
需求人數(shù)：3 人 地點(diǎn)：重慶市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長(zhǎng)沙市,永州市,郴州市,衡陽(yáng)市
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 上海瑞禾通訊技術(shù)有限公司 聘：廣州中高級(jí)工程師
需求人數(shù)：3 人 地點(diǎn)：廣州市
熱點(diǎn)問(wèn)題
更多精彩
| 聯(lián)系我們 - 問(wèn)通信專家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |