UE功率異常專題分析項目名稱保定電信TD項目文檔編號001版本號V1.0作者周應(yīng)川版權(quán)所有大唐移動通信設(shè)備有限公司本資料及其包含的所有內(nèi)容為大唐移動通信設(shè)備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關(guān)著作權(quán)法律的保護。未經(jīng)大唐移動書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動或以其它方式使用本資料的部分或全部內(nèi)容，違者將被依法追究責任。文檔更新記錄日期更新人版本備注2008-周應(yīng)川V1.0完成初稿

引言編寫目的本專題討論的是上行內(nèi)環(huán)功控，由于上行內(nèi)環(huán)功控是由基站協(xié)助UE，對UE的發(fā)射功率做出調(diào)整，從而使移動臺始終保持最理想的發(fā)射功率。基站每隔一定時間檢測一次解調(diào)后的上行業(yè)務(wù)信道SIR，然后與期望值（即SIRtarget）進行比較，若高于目標值則發(fā)送一個降低發(fā)射功率的指令；反之，則發(fā)送一個增加發(fā)射功率的指令。以上是正常的功率控制過程，但如果由異常的情況出現(xiàn)，上行內(nèi)環(huán)功率控制已經(jīng)失效，無法正?？刂芔E發(fā)射功率，造成掉話等現(xiàn)象。討論在各種情況下出現(xiàn)的導致UE功率異常的情況。預(yù)期讀者和閱讀建議本文檔預(yù)期讀者為中客服中心網(wǎng)絡(luò)優(yōu)化人員文檔約定文檔格式遵守公司技術(shù)類文檔模板要求。參考資料《無線網(wǎng)絡(luò)和業(yè)務(wù)參數(shù)標定手冊1.6.5》縮寫術(shù)語功率升高的原因（上行同步失步）的解釋功率升高在和研究進行溝通后發(fā)現(xiàn)是上行同步出窗造成的UE已經(jīng)失去上行同步后無法控制功率，以最大功率要求建立上行同步。孤嶼UE獲得上行同步分為外環(huán)同步和內(nèi)環(huán)同步。外環(huán)同步控制的功能是對上行閉環(huán)同步控制的目標值Target_user進行調(diào)整，原則是保證時隙內(nèi)所有用戶的信道沖擊響應(yīng)在窗內(nèi)，且最可能地向時隙的目標值位置調(diào)整。外環(huán)同步調(diào)整所需輸入?yún)?shù)和配置參數(shù)如下：輸入值：，M1測量得到的第i個CCTrCH的第n個子幀CIR的start值；，M1測量得到的第i個CCTrCH的第n個子幀CIR的end值；peak，上行閉環(huán)同步控制中計算得到的第i個CCTrCH的peak的均值；start，上行閉環(huán)同步控制中計算得到的第i個CCTrCH的start的均值；end，上行閉環(huán)同步控制中計算得到的第i個CCTrCH的end的均值；配置參數(shù)：K，信道估計窗的個數(shù)，由NBAP的Midamble_K參數(shù)配置；取值范圍K=2，4，6，8，10，12，14，16Ncount，外環(huán)同步控制周期，由OM配置；取值范圍〔0…255〕Counter_start_thre，CIRstart計數(shù)器門限值，由OM配置；取值范圍〔0…255〕Counter_end_thre，CIRend計數(shù)器門限值，由OM配置；取值范圍〔0…255〕 輸出值：輸出Target_user給上行內(nèi)環(huán)同步控制模塊。外環(huán)同步調(diào)整的原則1.保證整個信道沖擊響應(yīng)在信道估計窗內(nèi)；2.將每個用戶的信道沖擊響應(yīng)Target_user向時隙的目標位置Target_ts進行調(diào)整；信道沖擊響應(yīng)出窗的約定在下面兩種情況下認為信道沖擊響應(yīng)出窗：情況（a）：如果M1傳遞給FC的信道沖擊響應(yīng)start的瞬時值為0，F(xiàn)C認為CIRstart已出窗。情況（b）：如果M1傳遞給FC的信道沖擊響應(yīng)end的瞬時值為，F(xiàn)C認為CIRend已出窗。對應(yīng)上面兩種情況，分別設(shè)置兩個計數(shù)器Counter_start和Counter_end。如果情況（a）發(fā)生，計數(shù)器Counter_start加1，與此相同情況（b）發(fā)生，計數(shù)器Counter_end加1。在Ncount子幀內(nèi)，如果計數(shù)器Counter_start或Counter_end達到了門限值，才認為是信道沖擊響應(yīng)出窗，外環(huán)同步需要按照出窗情況進行調(diào)整。否則，如果計數(shù)器Counter_start或Counter_end沒有在Ncount子幀內(nèi)達到了門限值，則計數(shù)器將被清零，外環(huán)同步不需按照出窗情況進行調(diào)整。外環(huán)同步調(diào)整的初始約定窗長計算公式為：，fix的操作是下取整。初始目標點的位置定義為：，ceil的操作是向上取整。在窗長大于16個chips的情況下，由于JD/M1子系統(tǒng)中僅用估計窗的前16個chips來做信道沖擊響應(yīng)的估計，因此初始目標點取值與窗長16的相同。時隙的目標位置Target_ts是該時隙所有用戶同步的目標位置，對該時隙的所有用戶都是一樣的，當本時隙窗的個數(shù)midamble_K確定后，此值就是確定的。時隙的目標位置取值為初始目標點的位置：Target_ts=Starting_target_point該時隙中每個用戶的初始目標位置取值為時隙的目標位置：Initial_Target_user=Target_ts在外環(huán)同步調(diào)整的算法公式中，信道估計窗的長度都是以1/8chip為單位的：下表列出了一個時隙中窗的個數(shù)、窗長和初始目標位置的關(guān)系：NumberofchannelestimationwindowsWL

[chip]WL*

[1/8chip]StartingPoint

[chip]264511643225566211676816127610129541210794149713168633CIR在信道估計窗內(nèi)的外環(huán)同步調(diào)整算法如果信道沖擊響應(yīng)CIR的start和end都位于信道估計窗內(nèi)，CIR的峰值peak超前于時隙的目標位置Target_ts，外環(huán)同步按照如下公式調(diào)整：(integerdivisiondownward)其中調(diào)整量Delta_target和峰值peak都是以1/8為單位的，而調(diào)整的用戶目標值Target_user要對齊到整chip上，需要對其進行取整操作。如果信道沖擊響應(yīng)CIR的start和end都位于信道估計窗內(nèi)，CIR的峰值peak落后于時隙的目標位置Target_ts，則外環(huán)同步按照如下公式調(diào)整：(Integerdivisionupward)CIR出窗情況下的外環(huán)同步調(diào)整算法如果計數(shù)器Counter_start在連續(xù)的Ncount子幀內(nèi)達到了門限值，認為是信道沖擊響應(yīng)的start出窗，如果計數(shù)器Counter_end在連續(xù)的Ncount子幀內(nèi)達到了門限值，則認為是信道沖擊響應(yīng)的end出窗，對以上兩種情況外環(huán)同步需要按照出窗情況進行調(diào)整。根據(jù)外環(huán)同步調(diào)整原則，當信道沖擊響應(yīng)出窗時，第一步是要將整個CIR移到窗內(nèi)。如果CIR的start出窗，CIR的end在窗內(nèi)，外環(huán)同步按照如下公式調(diào)整，此時無需考慮peak值是超前、相等還是落后于時隙的目標位置Target_ts：(integerdivisiondownward)如果CIR的end出窗，CIR的start在窗內(nèi)，外環(huán)同步按照如下公式調(diào)整，此時無需考慮peak值是超前、相等還是落后于時隙的目標位置Target_ts：(integerdivisionupward)異常情況外環(huán)同步調(diào)整算法如果CIR的start出窗，CIR的end在窗內(nèi)但與信道估計窗尾的距離在1個chip之內(nèi)，則外環(huán)同步無法作出調(diào)整，此時Target_user僅做取整處理：(integerdivision)如果CIR的end出窗，CIR的start在窗內(nèi)但與信道估計窗頭的距離在1個chip之內(nèi)，則外環(huán)同步無法作出調(diào)整，此時Target_user僅做取整處理：(integerdivision)如果CIR的start和end兩端都出窗，外環(huán)同步控制不做調(diào)整，Target_user保持不變。案例1：上行同步出窗導致UE功率升高掉話【測試環(huán)境參數(shù)】DT測試方式：CS12.2K語音測試MOC呼叫118保持長呼狀態(tài)測試軟件：OUTUM3.5測試終端：DTM8110PECKER2硬件版本：1.10.00軟件版本：1.20.07_1219測試平均車速度：90KM/H測試路線所屬RNC：保定RNC＝2496【問題現(xiàn)象】在保定日常優(yōu)化測試中，從OUTUM測試軟件端經(jīng)常發(fā)現(xiàn)UE功率無任何原因異常升高到24dbm，接著發(fā)生CELLUPDATE，但無一次成功，最后發(fā)生掉話。此現(xiàn)象普遍存在在郊縣其站間距相距較遠的區(qū)域中，在密集的城區(qū)此現(xiàn)象還沒出現(xiàn)過。郊縣DT測試中有95％的掉話都為此現(xiàn)象。對此現(xiàn)象，我們結(jié)合外場測試的LOG分析和機房UE跟蹤TRACE敘述問題的情況如下：下面針對最近測試的一段測試LOG中選取其中一個掉話點進行問題的描述和分析。如下圖1：測試基站南張為09A宏基站。圖1UE功率異常升高前測試覆蓋圖從圖1的測試效果圖可以看到當前UE占用南張2，其功率升高前各種參數(shù)都在理想狀態(tài)。圖2UE功率異常升高到24dbm覆蓋圖上圖圖2的測試打點和圖1是相鄰的，從圖2中可以發(fā)現(xiàn)在一個測試點的間隔中，UE發(fā)射功率猛然升高到24dbm，但這個時候南張2的PCCPCH-RSCPPCCPCH-C/I都在正常范圍，唯一就是UE發(fā)射功率為最大值。此現(xiàn)象一直持續(xù)到圖中掉話點，且功率再也無法下降。在掉話前UE要求CELLUPDATE，但不成功，最后造成DROPCALL。如下圖：圖3掉話前的一次CELLUPDATE從圖3可以看到在掉話前有一次CELLUPDATE，但沒有成功。圖4CELLUPDATE信令解碼后圖4為CELLUPDATE信令的解碼，原因為無線鏈路失敗。以上現(xiàn)象是通過OUTUM測試中發(fā)現(xiàn)的問題。下面從機房UE跟蹤TRACE中發(fā)現(xiàn)的問題進行問題的描述和分析如下圖：圖5RADIOLINKFAILUREINDICATION信息解碼從圖5克看到NODEB向RNC發(fā)送一條RADIOLINKFAILUREINDICATION無線鏈路失敗指示。指示的原因為同步失敗。由于NODEB發(fā)送了同步失敗信令，RNC主動要求CN側(cè)釋放IU口資源，并釋放所以資源。其中IURELEASEREQUEST的信令解碼如下：圖6IURELEASEREQUEST信令解碼從圖6可以看到，RNC主動要求進行IU口釋放的原因為“和UE的無線連接丟失”。發(fā)生此信令之后釋放所有接口資源，引發(fā)一次掉話。綜合以上分析可以看到，NodeB側(cè)無線鏈路失敗指示過程是對用戶Iub接口無線鏈路狀態(tài)檢測的結(jié)果，該過程用于NodeB向RNC指示一條無線鏈路發(fā)生了異常或不可用，并且該鏈路無法恢復(fù)。應(yīng)該是由于無線鏈路失敗是NODEB上報的，所以CELLUPDATE無法挽救。在無線鏈路已經(jīng)成功建立后的任何時刻，當NodeB檢測到無線鏈路異常時都可以發(fā)起RadioLinkFailureIndication過程。此現(xiàn)象沒有發(fā)生在切換帶，從信令上觀察也沒有切換的報告，其接收電平和干擾都在正常范圍。如果是考慮上行干擾，不應(yīng)該郊縣全網(wǎng)都會這樣。此現(xiàn)象在郊縣全網(wǎng)普遍存在。且每次無線鏈路失敗的信令都是NODEB上報給RNC，并不是UE上報。在案例1中對終端進行升級后，此現(xiàn)象已經(jīng)消除，故障是由于終端在上行同步算法中存在BUG導致上行同步出窗，UE在失步以后要求建立上行同步，但始終建立不上，所以終端以最大功率發(fā)射，要求建立上行同步。案例2:無線鏈路失?。ǘ〞r器超時）引起上行同步失敗故障現(xiàn)象在保定市區(qū)優(yōu)化時，測量路線從石化賓館向長城公寓方向，發(fā)生CS12.2K測試掉話。案例分析在測試路線從石化賓館開始，經(jīng)過長城公寓后，UE向RNC發(fā)送測量報告，目標小區(qū)為發(fā)展大廈2小區(qū)（10087－96），但是由于切換失敗發(fā)生了掉話。圖1圖2從圖1和圖2分析來看，當前UE駐留在石化賓館2小區(qū)，要求發(fā)生切換，從圖1服務(wù)小區(qū)和鄰區(qū)測量列表中可以看到，最強的鄰區(qū)有發(fā)展大廈2和建委3，切換發(fā)生目標小區(qū)為發(fā)展大廈2。為同頻接力切換，RNC向UE發(fā)生了物理信道重配，從圖2可以觀察到?jīng)]有UE沒有回應(yīng)物理信道重配完成。此時PCCPCHC/I=-13，已經(jīng)非常差了。從機房跟蹤到TRACE分析如下：圖3從圖3分析看到RNC向UE發(fā)送了物理信道重配消息，目標小區(qū)NODEB也向UE發(fā)送了RADIOLINKRESTOREINDICATION，但由于物理層的失步，造成原小區(qū)和目標小區(qū)同時向RNC發(fā)送RADIOLINKFAILUREINDICATION表示無線鏈路建立失敗。隨后RNC會主動向CN發(fā)送IURELEASEREQUEST引起一次切換掉話。從RADIOLINKFAILUREINDICATION解析的信令可以看到：圖4從圖4RADIOLINKFAILUREINDICATION可以看到無線鏈路失敗的指示為同步失敗。而一個正常的接力切換流程圖應(yīng)該為如圖5：圖5綜合以上的分析，由于原小區(qū)石化賓館2的主頻點為10087，鄰區(qū)中建委3和發(fā)展大廈2主頻點都為10087，對測試問題點的覆蓋PCCPCH-RSCP都在－70dbm左右，有越區(qū)覆蓋的問題。在切換中UE受到10087下行干擾導致物理同步失敗。暫時把問題定位為UE受到下行干擾導致切換失敗掉話。產(chǎn)生以上原因是因為切換過程中RL質(zhì)量惡化，網(wǎng)絡(luò)側(cè)（在定時器時間內(nèi)）檢測不到UE的回應(yīng)數(shù)據(jù)，原NodeB和目標NODEB均向RNC發(fā)送RadioLinkFailure，指示同步失敗。案例處理綜合案例分析中產(chǎn)生掉話的各種原因，我們采取了以下兩個措施分析：檢查“小區(qū)配置”->“無線鏈路失敗過程定時器”正常的默然值為10，也是1秒。檢查以后發(fā)現(xiàn)石化賓館2小區(qū)OMCR上配置也是正常值為10。如下圖：圖6該參數(shù)值會影響NodeB對RL恢復(fù)的判斷準則，如果不合適，NodeB會無法及時檢測到RLRestore，或者RLRestore頻繁出現(xiàn)，造成系統(tǒng)異常。如果該參數(shù)設(shè)置過大，可能導致通話質(zhì)量差的UE占用無線信道，降低資源利用率。如果該參數(shù)設(shè)置過小，可能導致則RL失敗過程較易發(fā)生，容易在啟動切換前引起RL故障而造成斷話。從TRACE跟蹤的信令中看到發(fā)生RADIOLINKRESTOREINDICATION時間為15:05:35，而RADIOLINKFAILUREINDICATION無線鏈路NODEB通知RNC的時間為15:05:39，前后時間相差4秒。4秒大于“無線鏈路失敗過程定時器”所以最終原因為無線鏈路失敗定時器超時UE無回應(yīng)引起的切換掉話。這種切換失敗會引起RNC主動要求釋放鏈路資源。所以引起的掉話。無線鏈路失敗是主要因為無線環(huán)境惡化（上下行干擾等）的原因，所以我們沒有采用1方法修改此定時器，而是想到排除干擾這方面。我們采用2方法（調(diào)整天線傾角，控制其覆蓋范圍，不要產(chǎn)生越區(qū)覆蓋）。2．綜合案列分析中的各種原因?qū)Πl(fā)展大廈2小區(qū)，建委3小區(qū)調(diào)整天線傾角，由原來5度調(diào)整為7度后，控制其覆蓋的范圍，通過調(diào)整后的測試分析，問題得到解決，沒有發(fā)生切換失敗圖6機房跟蹤TRACE如下：從圖5和圖6中可以看到，天線調(diào)整后PCCPCHC/I明顯改善，且切換恢復(fù)正常，沒有發(fā)生掉話。案例3：鄰區(qū)中出現(xiàn)同頻同碼導致UE功率升高故障現(xiàn)象在保定107國道進行鄰區(qū)優(yōu)化發(fā)現(xiàn)，在西石橋3小區(qū)向西石橋1小區(qū)切換時候，UE上報MEASUREREPORT時候，一直發(fā)生切換失敗，如下：圖1切換失敗時候測試顯示故障分析從圖1的測試效果圖看到，當從西石橋3切換到西石橋1時候，一直發(fā)生切換失敗，切換失敗的原因從信令解碼后有下圖：圖2物理信道重配置失敗信令解碼結(jié)合圖1和圖2看到切換失敗一直持續(xù)到最終掉話，通過UETRACE跟蹤信令發(fā)現(xiàn)有如下現(xiàn)象：圖3物理信道重配失敗信令解碼從圖3可以看到，正常切換過程中的一條信令RADIOLINKRESTORE非常重要，它的作用是目標NODEB小區(qū)告訴RNC“我已經(jīng)和UE建立好上行同步了，可以切換了”，但是通過上圖可以看到?jīng)]有目標小區(qū)的同步信息，一直和目標小區(qū)同步不上。通過解碼測量控制信息（MEASURECONTROL），可以看到如下信息：圖4西石橋1下發(fā)的測量控制信息在MAPINFO圖中可以看到西石橋1小區(qū)的鄰居如下：圖5西是橋3小區(qū)鄰區(qū)顯示從圖5中可以看到由于西石橋1小區(qū)頻點碼字為：10079－22，而在西石橋3小區(qū)有：西石橋1、興隆酒店1。但它們?yōu)橥l同碼字。終上分析，鄰區(qū)中出現(xiàn)同頻同碼后，無法和目標小區(qū)做上行預(yù)同步，如果在鄰進的小區(qū)中沒有加到鄰區(qū)中，也會出現(xiàn)以上現(xiàn)象。判斷這種問題有下面兩種的方法：第一種方法：沒有跟蹤UETRACE的方法（準確不高）判斷圖1：物理信道重配時候RSCP值判斷圖2：物理信道重配失敗時候RSCP值判斷圖3：物理信道失敗后RSCP值又恢復(fù)正常通過前3個圖可以判斷和目標小區(qū)的同步是失敗的，因為源小區(qū)和目標小區(qū)在同步時候，信號電平突然變?yōu)橄嗤傧瘢?。第二種方法：分析UETRACE（準確度較高）以本例為準，本來是準備從西石橋3小區(qū)切換到西石橋1小區(qū)，那么在測量報告上報后建立完無線鏈路資源后會建立IUB口的AAL2承載，如下圖：判斷圖4：AAL2承載建立信令通過上圖可以看到RNC和目標小區(qū)建立完無線鏈路資源后，會建立AAL2承載，通過IUBC_ALCAP_EST_REQ可以看到建立的目標基站NODEB_ID＝55，正好就是上面說的同頻同碼小區(qū)興隆酒店，而西石橋的正確NODEB_ID=163，目標小區(qū)已經(jīng)建立錯誤。這就是為什么切換失敗的原因，其實這個例子是特例，從“RADIOLINKSETUPREQUEST”也能看出來，因為此切換失敗是發(fā)生在同一NODEB內(nèi)，所以切換無線鏈路建立應(yīng)該為“RADIOLINKADDINTIONREQUEST”故障解決刪除興隆酒店鄰區(qū)后復(fù)測，切換已經(jīng)正常，沒有出現(xiàn)切換失敗的情況。案例4：RNC沒有收到測量報告導致UE功率升高故障現(xiàn)象：在保定市區(qū)南線進行CS64K測試時候，發(fā)現(xiàn)在切換過程中UE功率升高導致掉話，測試的信令圖如下：圖1UE功率升高信令圖從上圖看到UE發(fā)送了測量報告，鄰區(qū)電平已經(jīng)很大了但就是不切換，直到最后掉話。故障分析：從跟蹤的信令流程圖可以看到如下：圖2RNC沒收到測量報告導致掉話從上圖的信令跟蹤TRACE可以看到RNC根本沒有收到UE發(fā)送的測量報告，導致IURELEASEREQUEST而引發(fā)掉話。最根本的原因是信令中的一條信令TPSS_HSPS_RLC_STATUS_IND，這條信令是標識業(yè)務(wù)處理子系統(tǒng)向高層信令子系統(tǒng)發(fā)送了RLC鏈路測量報告，也就是我們平時在配置NODEB專用測量中事件F報告準則。對TPSS_HSPS_RLC_STATUS_IND解碼后的信令如下圖：圖3TPSS_HSPS_RLC_STATUS_IND信令解碼顯示在上面的圖中可以看到RLC發(fā)生不可恢復(fù)的錯誤導致RNC主動發(fā)送IURELEASE請求，其中TPSS_HSPS_RLC_STATUS_IND是上行鏈路檢測對RSCP或者SIR發(fā)送錯誤時候發(fā)送的，我們在NBAP專用測量中可以看到下面的流程：圖4NODEB專用測量（事件F）由基站測量并報告RNC，測量類型采用RSCP、或者SIR，可以通過操作維護配置。RNC為用戶建立無線鏈路之后（收到RBSETUPCOMPLETE消息后），向基站發(fā)起專用測量初始化消息，通知基站進行RSCP或者SIR的測量（事件F）UE發(fā)送切換之后，RNC需要向NODEB發(fā)起專用測量初始化消息，通知基站進行RSCP或者SIR的測量（事件F）。通話中發(fā)生切換后RNC向NODEB發(fā)起專用測量初始化消息的信令是在測量控制以后發(fā)出的，如下圖：圖5專用測量初始化消息的信令在上面的分析中看到，掉話是由于RNC沒有收到UE發(fā)送的測量報告導致無線鏈路惡化而掉話，表現(xiàn)在UU口為終端功率以24DBM發(fā)射，且SIR值較差，NODEB專用測量上行鏈路惡化情況在下圖設(shè)置圖6NODEB專用測量設(shè)置從上圖可以看到，上行鏈路測量類型為SIR，該測量量用于RLS算法中無線鏈路監(jiān)測。但是通過下圖：圖7RLS算法從上圖可以看到，如果出現(xiàn)NODEBF事件的報告，像上圖的配置，那么RLS算法是不起作用的，必須把“上行無線鏈路監(jiān)測算法開關(guān)”修改為“打開”，“上行鏈路監(jiān)測方法”修改為“NODEB專用測量”。只有這樣在圖6中設(shè)置的NODEB專用測量才有效。案例5：CS64K中上下行業(yè)務(wù)同時隙干擾導致UE功率升高在保定進行CS64K測試中發(fā)現(xiàn)如果兩個測試終端同時做VP測試時候，如果業(yè)務(wù)被分配在同時隙（上、下行），當兩個UE相隔較近時候會產(chǎn)生嚴重的同頻干擾，其中有一部終端發(fā)送的測量報告RNC并沒有收到，最終不能切換，導致UE發(fā)射功率升高。如下圖：圖1信號測試信令圖從上圖看到UE已經(jīng)發(fā)送測量報告，但是一直沒有切換導致功率升高，最終掉話，可以注意到由于2部終端都使用上行1時隙，下行4時隙。那么在4時隙上有非常大的下行干擾ISCP(4)為：-58DBM。而業(yè)務(wù)信道的DPCHRSCP(4)=-86DBM。由于兩部終端占用相同的上下行時隙，所以存在較大的下行干擾。查看供銷印刷廠1小區(qū)的DCA算法，如下圖：而基于固定的算法會導致兩部測試終端的業(yè)務(wù)分配到同一時隙。對于‘業(yè)務(wù)所需碼資源<BRU_TS_TH’的接入請求從一個方向接入（該時隙優(yōu)先級隊列由操作維護配置）；‘業(yè)務(wù)所需碼資源>=BRU_TS_TH’的接入請求，從相反方向接入。具體流程如圖所示。圖STYLERE