 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
請(qǐng)問Service Request消息是什么意思？
提問者:
• MM和GMM的區(qū)別，MM_AUTHENTICATION_reQUEst和GMM_AUTHENTICATION_AND_CYPHERING_reQUEst的區(qū)別 2019-12-30
• 被叫出現(xiàn)多次鑒權(quán)失敗：AuthenticationreQUEst后沒有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢VideoPlayreQUEstFailure-視頻播放請(qǐng)求失敗-原因 2018-05-21
• CSFB沒有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)失敗：AuthenticationreQUEst后沒有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢VideoPlayreQUEstFailure-視頻播放請(qǐng)求失敗-原因 2018-05-21
• CSFB沒有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
問題答案
( 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)求的類型有：1、主叫，2、位置更新，3、短信和緊急呼叫；一般打電話都是請(qǐng)求主叫類型，BTS接受請(qǐng)求后就分配給手機(jī)TCH信道可以通話
回答者：
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是不同的，或者說UE認(rèn)為Service Request流程成功完成的標(biāo)志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應(yīng)答應(yīng)該是接收到來自低層的一個(gè)指示，通知上層安全模式控制流程已經(jīng)完成，收到這個(gè)指示，高層則明白Service Request流程已經(jīng)正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應(yīng)該是一個(gè)Service Accept消息。這是一個(gè)顯示的通知消息。
這樣做的目的，覺得是因?yàn)榍罢咴赑MM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或?qū)aging的應(yīng)答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來作為隱式的應(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è)沒有激活。否則UE是不清楚的，因此就沒辦法完成將數(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是不同的，或者說UE認(rèn)為Service Request流程成功完成的標(biāo)志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應(yīng)答應(yīng)該是接收到來自低層的一個(gè)指示，通知上層安全模式控制流程已經(jīng)完成，收到這個(gè)指示，高層則明白Service Request流程已經(jīng)正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應(yīng)該是一個(gè)Service Accept消息。這是一個(gè)顯示的通知消息。
這樣做的目的，覺得是因?yàn)榍罢咴赑MM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或?qū)aging的應(yīng)答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來作為隱式的應(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è)沒有激活。否則UE是不清楚的，因此就沒辦法完成將數(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ù)有限公司
聘：成都移動(dòng)后臺(tái)高級(jí)
需求人數(shù)：1 人 地點(diǎn)：成都市
• 嘉環(huán)科技股份有限公司 聘：電信原廠網(wǎng)優(yōu)工程師
需求人數(shù)：3 人 地點(diǎn)：長沙市,衡陽市
• 浙江省郵電工程建設(shè)有限公司 聘：網(wǎng)優(yōu)日常租賃人員
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：電聯(lián)招聘督導(dǎo)、傳輸、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 廣東南方通信建設(shè)有限公司 聘：日常項(xiàng)目系統(tǒng)中高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：百色市
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 西安長河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：安康市
• 西安中興精誠通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
需求人數(shù)：1 人 地點(diǎn)：成都市
• 嘉環(huán)科技股份有限公司 聘：電信原廠網(wǎng)優(yōu)工程師
需求人數(shù)：3 人 地點(diǎn)：長沙市,衡陽市
• 浙江省郵電工程建設(shè)有限公司 聘：網(wǎng)優(yōu)日常租賃人員
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：電聯(lián)招聘督導(dǎo)、傳輸、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 廣東南方通信建設(shè)有限公司 聘：日常項(xiàng)目系統(tǒng)中高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：百色市
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 西安長河通訊有限責(zé)任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：安康市
• 西安中興精誠通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
熱點(diǎn)問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |