 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
請問Service Request消息是什么意思？
提問者:
• MM和GMM的區(qū)別，MM_AUTHENTICATION_reQUEst和GMM_AUTHENTICATION_AND_CYPHERING_reQUEst的區(qū)別 2019-12-30
• 被叫出現(xiàn)多次鑒權失敗：AuthenticationreQUEst后沒有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢VideoPlayreQUEstFailure-視頻播放請求失敗-原因 2018-05-21
• CSFB沒有TrackingareaupdatereQUEst顯示CSFB失敗，可以解決嗎，有什么影響 2018-05-08
• ReEstSetupreQUEstNumber什么建立請求？ 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)多次鑒權失敗：AuthenticationreQUEst后沒有AuthenticationreQUEst什么原因 2018-08-28
• 咨詢VideoPlayreQUEstFailure-視頻播放請求失敗-原因 2018-05-21
• CSFB沒有TrackingareaupdatereQUEst顯示CSFB失敗，可以解決嗎，有什么影響 2018-05-08
• ReEstSetupreQUEstNumber什么建立請求？ 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 )
服務請求
回答者：
朱小龍AA
回答時間：2012-05-27 01:03
7
15
BTD指配MS SDCCH后，MS發(fā)送Service Request服務請求給BTS，請求的類型有：1、主叫，2、位置更新，3、短信和緊急呼叫；一般打電話都是請求主叫類型，BTS接受請求后就分配給手機TCH信道可以通話
回答者：
zbxzcx2006
回答時間：2012-05-28 11:36
7
11
BTD打錯了 是BTS
zbxzcx2006 2012-05-28 11:39
設計到服務管理的，應該不是BTS控制的吧，應該是msc server控制的
wuhaidong 2012-05-30 16:06
UL:CM Service request CM服務請求
在TS24.008中，關于Service Request消息的正確應答，在V3.5版本做了更新。之前的有不正確的地方。
以下是CR的一些具體內容,在V3.5后進行了更新.
________________________________________________________________________________________
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ù)要求，對TS24.008的內容做了更新，體現(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認為Service Request流程成功完成的標志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應答應該是接收到來自低層的一個指示，通知上層安全模式控制流程已經完成，收到這個指示，高層則明白Service Request流程已經正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應該是一個Service Accept消息。這是一個顯示的通知消息。
這樣做的目的，覺得是因為前者在PMM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或對Paging的應答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來作為隱式的應答。而在PMM-CONNECTED狀態(tài)的UE發(fā)送Service Request消息，通常是為了將一個或多個RAB重新激活，因為這個UE可能剪了了多個RAB，因為RAB和PDP上下文是一一對應的。那可能只有一個是激活的，剩下的其他RAB可能處于inactive的狀態(tài)，但因為有一個RAB是活的，所以UE仍處于PMM-CONNECTED狀態(tài)。所以這時如果UE發(fā)送了Service Request消息，則需要核心網(wǎng)明確的告知自己到底哪幾個RAB已經激活，哪幾個沒有激活。否則UE是不清楚的，因此就沒辦法完成將數(shù)據(jù)映射到RAB的工作了。
在TS24.008中，關于Service Request消息的正確應答，在V3.5版本做了更新。之前的有不正確的地方。
以下是CR的一些具體內容,在V3.5后進行了更新.
________________________________________________________________________________________
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ù)要求，對TS24.008的內容做了更新，體現(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認為Service Request流程成功完成的標志是不同的。如果是在PMM-IDLE狀態(tài)下發(fā)送Service Request消息，那正確的應答應該是接收到來自低層的一個指示，通知上層安全模式控制流程已經完成，收到這個指示，高層則明白Service Request流程已經正確完成了。
而如果在PMM-CONNECTED狀態(tài)下的UE發(fā)送Service Request消息，那正確的Response應該是一個Service Accept消息。這是一個顯示的通知消息。
這樣做的目的，覺得是因為前者在PMM-IDLE狀態(tài)發(fā)Service Request通常是重建Iu連接或對Paging的應答，因此為了減少數(shù)據(jù)傳遞的延遲，可以由核心網(wǎng)發(fā)起安全模式的建立來作為隱式的應答。而在PMM-CONNECTED狀態(tài)的UE發(fā)送Service Request消息，通常是為了將一個或多個RAB重新激活，因為這個UE可能剪了了多個RAB，因為RAB和PDP上下文是一一對應的。那可能只有一個是激活的，剩下的其他RAB可能處于inactive的狀態(tài)，但因為有一個RAB是活的，所以UE仍處于PMM-CONNECTED狀態(tài)。所以這時如果UE發(fā)送了Service Request消息，則需要核心網(wǎng)明確的告知自己到底哪幾個RAB已經激活，哪幾個沒有激活。否則UE是不清楚的，因此就沒辦法完成將數(shù)據(jù)映射到RAB的工作了。
回答者：
xhy1331
回答時間：2012-06-03 15:35
9
9
手機告訴交換或核心網(wǎng)，我要干嘛，要交換提供什么服務。
回答者：
藍培清
回答時間：2012-06-08 11:51
11
14
• 廣東南方通信建設有限公司
聘：日常項目系統(tǒng)中高級工程師
需求人數(shù)：2 人 地點：百色市
• 廣東世炬網(wǎng)絡科技股份有限公司 聘：家寬核心技術棧開發(fā)
需求人數(shù)：1 人 地點：云南省
• 重慶信科通信工程有限公司 聘：上饒電信中興原廠高級
需求人數(shù)：2 人 地點：上饒市
• 南京華蘇科技有限公司 聘：網(wǎng)優(yōu)工程師
需求人數(shù)：1 人 地點：沈陽市
• 杭州東信網(wǎng)絡技術有限公司 聘：中興網(wǎng)優(yōu)工程師-遼寧大連移動
需求人數(shù)：10 人 地點：大連市
• 河南創(chuàng)賽通信科技有限公司 聘：急聘！廣西單驗簇優(yōu)化
需求人數(shù)：49 人 地點：廣西省
• 黑龍江電信國脈工程股份有限公司 聘：華為無線督導后臺工程師
需求人數(shù)：4 人 地點：大慶市
• 中徽建技術有限公司 聘：華為網(wǎng)絡PTN、OTN傳輸工程師
需求人數(shù)：2 人 地點：合肥市
• 陜西瑞達灃通信技術有限公司 聘：華為5G工程單驗工程師
需求人數(shù)：10 人 地點：吐魯番市,哈密市
• 西安長河通訊有限責任公司 聘：中興OTN工程師（高級）
需求人數(shù)：1 人 地點：紅河州
需求人數(shù)：2 人 地點：百色市
• 廣東世炬網(wǎng)絡科技股份有限公司 聘：家寬核心技術棧開發(fā)
需求人數(shù)：1 人 地點：云南省
• 重慶信科通信工程有限公司 聘：上饒電信中興原廠高級
需求人數(shù)：2 人 地點：上饒市
• 南京華蘇科技有限公司 聘：網(wǎng)優(yōu)工程師
需求人數(shù)：1 人 地點：沈陽市
• 杭州東信網(wǎng)絡技術有限公司 聘：中興網(wǎng)優(yōu)工程師-遼寧大連移動
需求人數(shù)：10 人 地點：大連市
• 河南創(chuàng)賽通信科技有限公司 聘：急聘！廣西單驗簇優(yōu)化
需求人數(shù)：49 人 地點：廣西省
• 黑龍江電信國脈工程股份有限公司 聘：華為無線督導后臺工程師
需求人數(shù)：4 人 地點：大慶市
• 中徽建技術有限公司 聘：華為網(wǎng)絡PTN、OTN傳輸工程師
需求人數(shù)：2 人 地點：合肥市
• 陜西瑞達灃通信技術有限公司 聘：華為5G工程單驗工程師
需求人數(shù)：10 人 地點：吐魯番市,哈密市
• 西安長河通訊有限責任公司 聘：中興OTN工程師（高級）
需求人數(shù)：1 人 地點：紅河州
熱點問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動通信網(wǎng) © 2006 - |