 |
善于提問(wèn)，勤于回答，你也是專(zhuān)家
|
 |
問(wèn)題已開(kāi)啟
(普通問(wèn)題)
請(qǐng)問(wèn)Service Request消息是什么意思？
提問(wèn)者:
• MM和GMM的區(qū)別，MM_AUTHENTICATION_reQUEst和GMM_AUTHENTICATION_AND_CYPHERING_reQUEst的區(qū)別 2019-12-30
• 被叫出現(xiàn)多次鑒權(quán)失�。篈uthenticationreQUEst后沒(méi)有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢(xún)VideoPlayreQUEstFailure-視頻播放請(qǐng)求失敗-原因 2018-05-21
• CSFB沒(méi)有TrackingareaupdatereQUEst顯示CSFB失敗，可以解決嗎，有什么影響 2018-05-08
• ReEstSetupreQUEstNumber什么建立請(qǐng)求？ 2018-05-07
• LTE里面的UEContextReleasereQUEstCAUSE 2018-01-25
• ENB接收UE的RRCConnectionreQUEst消息次數(shù)怎么區(qū)分是不是重發(fā)的消息？ 2017-10-24
• 從LTE重選到UMTS小區(qū)后，RRCConnectionreQUEst消息的建立原因是如下哪種？（） 2017-08-29
• 被叫出現(xiàn)多次鑒權(quán)失�。篈uthenticationreQUEst后沒(méi)有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢(xún)VideoPlayreQUEstFailure-視頻播放請(qǐng)求失敗-原因 2018-05-21
• CSFB沒(méi)有TrackingareaupdatereQUEst顯示CSFB失敗，可以解決嗎，有什么影響 2018-05-08
• ReEstSetupreQUEstNumber什么建立請(qǐng)求？ 2018-05-07
• LTE里面的UEContextReleasereQUEstCAUSE 2018-01-25
• ENB接收UE的RRCConnectionreQUEst消息次數(shù)怎么區(qū)分是不是重發(fā)的消息？ 2017-10-24
• 從LTE重選到UMTS小區(qū)后，RRCConnectionreQUEst消息的建立原因是如下哪種？（） 2017-08-29
問(wèn)題答案
( 4 )
服務(wù)請(qǐng)求
回答者：
朱小龍AA
回答時(shí)間：2012-05-27 01:03
7
15
BTD指配MS SDCCH后，MS發(fā)送Service Request服務(wù)請(qǐng)求給BTS，請(qǐng)求的類(lèi)型有：1、主叫，2、位置更新，3、短信和緊急呼叫；一般打電話(huà)都是請(qǐng)求主叫類(lèi)型，BTS接受請(qǐng)求后就分配給手機(jī)TCH信道可以通話(huà)
回答者：
zbxzcx2006
回答時(shí)間：2012-05-28 11:36
7
11
BTD打錯(cuò)了 是BTS
zbxzcx2006 2012-05-28 11:39
設(shè)計(jì)到服務(wù)管理的，應(yīng)該不是BTS控制的吧，應(yīng)該是msc server控制的
wuhaidong 2012-05-30 16:06
UL:CM Service request CM服務(wù)請(qǐng)求
在TS24.008中，關(guān)于Service Request消息的正確應(yīng)答，在V3.5版本做了更新。之前的有不正確的地方。
以下是CR的一些具體內(nèi)容,在V3.5后進(jìn)行了更新.
________________________________________________________________________________________
Title: Clarification of response handling of Service Request
Source: Siemens AG
Work item code: GPRS
Reason for change:The decision was taken that security mode control procedure is the only valid
positive response on SERVICE REQUEST in PMM-IDLE and SERVICE ACCEPT is the only valid positive response in mode PMM-CONNECTED.
The description for MS is clarified as far as the action is concerned which has to be taken after receiving response.
________________________________________________________________________________________
因此，根據(jù)要求，對(duì)TS24.008的內(nèi)容做了更新，體現(xiàn)在4.7.13.3章節(jié)。
If the SERVICE REQUEST message was sent in PMM-IDLE mode, the indication from the lower layers that the
security mode control procedure is completed (刪除了or reception of a SERVICE ACCEPT message), shall be treated as a successful completion of the procedure. The timer T3317 shall be stopped, and the MS enters GMM-REGISTERED state and PMM-CONNECTED mode.
If the SERVICE REQUEST message was sent in PMM-CONNECTED mode, then the reception of the SERVICE
ACCEPT message shall be treated as a successful completion of the procedure. The timer T3317 shall be stopped
and the MS remains in PMM-CONNECTED mode.
從上述文字規(guī)范了在PMM-IDLE狀態(tài)和PMM-CONNECTED狀態(tài)下發(fā)送Service Request消息，收到的正確的Response是不同的，或者說(shuō)UE認(rèn)為Service Request流程成功完成的標(biāo)志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應(yīng)答應(yīng)該是接收到來(lái)自低層的一個(gè)指示，通知上層安全模式控制流程已經(jīng)完成，收到這個(gè)指示，高層則明白Service Request流程已經(jīng)正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應(yīng)該是一個(gè)Service Accept消息。這是一個(gè)顯示的通知消息。
這樣做的目的，覺(jué)得是因?yàn)榍罢咴赑MM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或?qū)aging的應(yīng)答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來(lái)作為隱式的應(yīng)答。而在PMM-CONNECTED狀態(tài)的UE發(fā)送Service Request消息，通常是為了將一個(gè)或多個(gè)RAB重新激活，因?yàn)檫@個(gè)UE可能剪了了多個(gè)RAB，因?yàn)镽AB和PDP上下文是一一對(duì)應(yīng)的。那可能只有一個(gè)是激活的，剩下的其他RAB可能處于inactive的狀態(tài)，但因?yàn)橛幸粋�(gè)RAB是活的，所以UE仍處于PMM-CONNECTED狀態(tài)。所以這時(shí)如果UE發(fā)送了Service Request消息，則需要核心網(wǎng)明確的告知自己到底哪幾個(gè)RAB已經(jīng)激活，哪幾個(gè)沒(méi)有激活。否則UE是不清楚的，因此就沒(méi)辦法完成將數(shù)據(jù)映射到RAB的工作了。
在TS24.008中，關(guān)于Service Request消息的正確應(yīng)答，在V3.5版本做了更新。之前的有不正確的地方。
以下是CR的一些具體內(nèi)容,在V3.5后進(jìn)行了更新.
________________________________________________________________________________________
Title: Clarification of response handling of Service Request
Source: Siemens AG
Work item code: GPRS
Reason for change:The decision was taken that security mode control procedure is the only valid
positive response on SERVICE REQUEST in PMM-IDLE and SERVICE ACCEPT is the only valid positive response in mode PMM-CONNECTED.
The description for MS is clarified as far as the action is concerned which has to be taken after receiving response.
________________________________________________________________________________________
因此，根據(jù)要求，對(duì)TS24.008的內(nèi)容做了更新，體現(xiàn)在4.7.13.3章節(jié)。
If the SERVICE REQUEST message was sent in PMM-IDLE mode, the indication from the lower layers that the
security mode control procedure is completed (刪除了or reception of a SERVICE ACCEPT message), shall be treated as a successful completion of the procedure. The timer T3317 shall be stopped, and the MS enters GMM-REGISTERED state and PMM-CONNECTED mode.
If the SERVICE REQUEST message was sent in PMM-CONNECTED mode, then the reception of the SERVICE
ACCEPT message shall be treated as a successful completion of the procedure. The timer T3317 shall be stopped
and the MS remains in PMM-CONNECTED mode.
從上述文字規(guī)范了在PMM-IDLE狀態(tài)和PMM-CONNECTED狀態(tài)下發(fā)送Service Request消息，收到的正確的Response是不同的，或者說(shuō)UE認(rèn)為Service Request流程成功完成的標(biāo)志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應(yīng)答應(yīng)該是接收到來(lái)自低層的一個(gè)指示，通知上層安全模式控制流程已經(jīng)完成，收到這個(gè)指示，高層則明白Service Request流程已經(jīng)正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應(yīng)該是一個(gè)Service Accept消息。這是一個(gè)顯示的通知消息。
這樣做的目的，覺(jué)得是因?yàn)榍罢咴赑MM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或?qū)aging的應(yīng)答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來(lái)作為隱式的應(yīng)答。而在PMM-CONNECTED狀態(tài)的UE發(fā)送Service Request消息，通常是為了將一個(gè)或多個(gè)RAB重新激活，因?yàn)檫@個(gè)UE可能剪了了多個(gè)RAB，因?yàn)镽AB和PDP上下文是一一對(duì)應(yīng)的。那可能只有一個(gè)是激活的，剩下的其他RAB可能處于inactive的狀態(tài)，但因?yàn)橛幸粋�(gè)RAB是活的，所以UE仍處于PMM-CONNECTED狀態(tài)。所以這時(shí)如果UE發(fā)送了Service Request消息，則需要核心網(wǎng)明確的告知自己到底哪幾個(gè)RAB已經(jīng)激活，哪幾個(gè)沒(méi)有激活。否則UE是不清楚的，因此就沒(méi)辦法完成將數(shù)據(jù)映射到RAB的工作了。
回答者：
xhy1331
回答時(shí)間：2012-06-03 15:35
9
9
手機(jī)告訴交換或核心網(wǎng)，我要干嘛，要交換提供什么服務(wù)。
回答者：
藍(lán)培清
回答時(shí)間：2012-06-08 11:51
11
14
• 浙江省郵電工程建設(shè)有限公司
聘：新疆中興中高級(jí)優(yōu)化工程師
需求人數(shù)：7 人 地點(diǎn)：昌吉市,博樂(lè)市,克拉瑪依市,石河子市
• 福州弘宇信合通信技術(shù)有限公司 聘：高級(jí)規(guī)劃工程師
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 西安長(zhǎng)河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)資源管理工程師
需求人數(shù)：3 人 地點(diǎn)：香港
• 杭州飛陽(yáng)科技有限公司 聘：高端大數(shù)據(jù)優(yōu)化人員
需求人數(shù)：5 人 地點(diǎn)：云南省,山西省
• 嘉環(huán)科技股份有限公司 聘：核心網(wǎng)工程師-IMC青海
需求人數(shù)：2 人 地點(diǎn)：西寧市
• 重慶信科通信工程有限公司 聘：上饒電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：上饒市
• 河南創(chuàng)賽通信科技有限公司 聘：廣州前臺(tái)測(cè)試工程師5人
需求人數(shù)：5 人 地點(diǎn)：廣州市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級(jí)前臺(tái)/寧夏中衛(wèi)
需求人數(shù)：2 人 地點(diǎn)：寧夏
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：青海華為4/5G中級(jí)前臺(tái)
需求人數(shù)：3 人 地點(diǎn)：果洛藏族自治州
• 安徽引途科技有限公司 聘：安徽皖北單驗(yàn)簇優(yōu)化測(cè)試
需求人數(shù)：10 人 地點(diǎn)：六安市,宿州市,亳州市,蚌埠市,阜陽(yáng)市
需求人數(shù)：7 人 地點(diǎn)：昌吉市,博樂(lè)市,克拉瑪依市,石河子市
• 福州弘宇信合通信技術(shù)有限公司 聘：高級(jí)規(guī)劃工程師
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 西安長(zhǎng)河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)資源管理工程師
需求人數(shù)：3 人 地點(diǎn)：香港
• 杭州飛陽(yáng)科技有限公司 聘：高端大數(shù)據(jù)優(yōu)化人員
需求人數(shù)：5 人 地點(diǎn)：云南省,山西省
• 嘉環(huán)科技股份有限公司 聘：核心網(wǎng)工程師-IMC青海
需求人數(shù)：2 人 地點(diǎn)：西寧市
• 重慶信科通信工程有限公司 聘：上饒電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：上饒市
• 河南創(chuàng)賽通信科技有限公司 聘：廣州前臺(tái)測(cè)試工程師5人
需求人數(shù)：5 人 地點(diǎn)：廣州市
• 河北中創(chuàng)盈和通信科技有限公司 聘：中級(jí)前臺(tái)/寧夏中衛(wèi)
需求人數(shù)：2 人 地點(diǎn)：寧夏
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：青海華為4/5G中級(jí)前臺(tái)
需求人數(shù)：3 人 地點(diǎn)：果洛藏族自治州
• 安徽引途科技有限公司 聘：安徽皖北單驗(yàn)簇優(yōu)化測(cè)試
需求人數(shù)：10 人 地點(diǎn)：六安市,宿州市,亳州市,蚌埠市,阜陽(yáng)市
熱點(diǎn)問(wèn)題
更多精彩
| 聯(lián)系我們 - 問(wèn)通信專(zhuān)家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |