專利名稱：補充業(yè)務的支持方法及裝置的制作方法
技術領域：
本發(fā)明涉及通信領域，具體而言，涉及一種補充業(yè)務的支持方法及裝置。
背景技術：
目前，很多通信系統(tǒng)都采用了本地交換功能。本地交換指的是主被叫用戶在符 合一定條件下，其通話(即傳輸用戶面數據)不再經過核心網，而是直接在主被叫兩個基站 之間進行的方式。這樣做的好處是，可以減少對核心網資源的占用，縮短了語音的傳輸時 延。節(jié)約了 Abis 口(基站和基站控制器之間的接口)等使用帶寬，為運營商和用戶都提供 了方便。本地交換最大的特點是用戶面數據不再經由核心網傳送而是直接在基站之間進 行。當通話采用上述方式傳遞時，可以認為是在本地交換模式下進行，相應地，傳統(tǒng)的通話 方式，就可以描述為在傳統(tǒng)模式下進行。本地交換模式是傳統(tǒng)通信系統(tǒng)的一種特殊應用，可以大大節(jié)約Abis 口等的帶寬 資源，但是也勢必引入了新的問題。例如，本地交換技術本身決定了用戶面的語音不再從核 心網轉接。但是，通信中應用也比較普遍的補充業(yè)務卻是基于核心網技術實現的。例如，常 見的補充業(yè)務包括彩鈴、呼叫轉移、呼叫保持等。如果通話的用戶面始終在基站本地交換， 而不經過核心網，則核心網無法實施附加功能。顯然，如果僅僅實現了以節(jié)約帶寬的本地交換而不考慮附加的補充業(yè)務的實現， 會大大限制用戶的應用，大大影響用戶感知度，降低用戶體驗，甚至會遭到用戶投訴。補充業(yè)務，主要指在正常通信業(yè)務功能上補充的附加功能。和通話相關的補充業(yè) 務大致可以分為以下幾類電話撥打時就需要確認類1 會議電話(CC)。電話未接通前轉接或發(fā)生類2 遇忙呼叫前轉(CFB)、無應答呼叫前轉(CFNA)、無 條件呼叫前轉(CFU)、限制呼叫(Barring call)，彩鈴。通話進行中同時增加新的通話類3 呼叫等待(CW)、呼叫保持(CH)。以上業(yè)務中，電話撥打時需要確認類1和電話未接通前轉接或發(fā)生類2的所有補 充業(yè)務，都是在電話發(fā)起時或未接通前發(fā)生。但是，新的通話類3，例如呼叫等待(CW)呼叫保持(CH)，其中，呼叫保持，是用戶 在通話期間，可以通過呼叫保持功能保持住第一個通話，然后再撥打另一個通話，并可在二 者之間切換。而呼叫等待，則剛好相反，是用戶在通話期間，接收到另外一個電話時，可以接 聽并在二者之間切換。呼叫保持與呼叫等待，在通話過程時什么階段應用是不可預見的。因為用戶可能 隨時在打電話期間進行呼叫保持或呼叫等待的。如果此時，用戶的語音還在本地交換的模 式下進行，那么就無法進行呼叫保持，因為呼叫保持的功能是通過核心網的特性實現的，而 在本地交換模式下，兩個用戶的通話鏈路是直接關聯的，當用戶接通了另一路電話時，原來 那路顯然是無法繼續(xù)的。因此，本地交換技術本身決定了它并不能直接支持補充業(yè)務。但是，呼叫保持和呼叫等待又是一種比較常見的業(yè)務類型。在本地交換應用越來越廣泛的今天，也需要考慮本地交換下補充業(yè)務，尤其是呼叫保持和呼叫等待業(yè)務的實現。 否則，盡管節(jié)約了帶寬，但是，用戶卻不能發(fā)起呼叫保持和呼叫等待，因而降低了用戶感知度。因而，針對上述幾類補充業(yè)務，結合本地交換功能，目前還缺乏支持上述補充業(yè)務 的技術方案。尤其是針對第3類業(yè)務(例如，呼叫保持和呼叫等待業(yè)務)，如何在本地交換 模式下實現對補充業(yè)務的支持，還缺乏解決該問題的技術方案。
發(fā)明內容
針對相關技術中還缺乏在本地交換模式下實現對補充業(yè)務的支持的技術方案的 問題，本發(fā)明提供了一種補充業(yè)務的支持方法及裝置，以解決上述問題至少之一。根據本發(fā)明的一個方面，提供了 一種補充業(yè)務的支持方法。根據本發(fā)明的補充業(yè)務的支持方法包括在通話處于本地交換模式時，基站控制 器獲取來自于正在通話的終端的消息，其中，消息攜帶有補充業(yè)務的申請信息；基站控制器 根據申請信息將通話從本地交換模式轉換為通信數據經由核心網傳送的傳統(tǒng)通話模式；基 站控制器將消息上報至核心網。優(yōu)選地，在基站控制器根據申請信息將終端從本地交換模式轉換為傳統(tǒng)通話模式 之前，上述方法還包括基站控制器將消息進行存儲。優(yōu)選地，在基站控制器將通話從本地交換模式轉換傳統(tǒng)通話模式失敗時，上述方 法還包括基站控制器構造補充業(yè)務拒絕消息，并發(fā)送至終端。優(yōu)選地，在基站控制器將消息上報至核心網之后，上述方法還包括當核心網無法 支持補充業(yè)務時，基站控制器對無法支持的狀態(tài)進行標識；當再次接收攜帶有申請信息的 消息時，基站控制器根據標識拒絕將消息上報至核心網。優(yōu)選地，在基站控制器將消息上報至核心網之后，上述方法還包括當核心網支持 補充業(yè)務時，基站控制器獲取并解析終端與核心網傳輸的信息；基站控制器根據信息確定 補充業(yè)務已經結束；基站控制器繼續(xù)將當前通話保持在傳統(tǒng)通話模式下，或者，在預設的補 充業(yè)務結束處理標識為是的情況下，將當前通話從傳統(tǒng)通話模式轉換至本地交換模式下。優(yōu)選地，將當前通話從傳統(tǒng)通話模式轉換至本地交換模式下包括基站控制器根 據設置的通話存在標識，判斷當前存在的通話是否為原通話，其中，原通話為本地交換模式 下的通話；在當前通話為原通話的情況下，基站控制器將當前通話從傳統(tǒng)通話模式轉換至 本地交換模式下。根據本發(fā)明的另一方面，提供了一種補充業(yè)務的支持方法。根據本發(fā)明的補充業(yè)務的支持方法包括在通話處于通信數據經由核心網傳送的 傳統(tǒng)通話模式時，基站控制器將呼叫方的標識信息與預設標識信息進行比較，確定是否一 致；在呼叫方的標識信息與預設標識信息一致的情況下，基站控制器禁止發(fā)起本地交換模 式的轉換。優(yōu)選地，在禁止發(fā)起本地交換模式的轉換之后，方法還包括基站控制器判斷預設 的允許本地交換標識的狀態(tài)；基站控制器根據允許本地交換標識的狀態(tài)確定是否進行模式 轉換。根據本發(fā)明的又一方面，提供了 一種補充業(yè)務的支持方法。
根據本發(fā)明的補充業(yè)務的支持方法包括在通話處于通信數據經由核心網傳送的 傳統(tǒng)通話模式時，基站控制器在獲取電話接通的指示信息之前，禁止發(fā)起本地交換模式的 轉換。根據本發(fā)明的再一方面，提供了 一種補充業(yè)務的支持裝置。根據本發(fā)明的補充業(yè)務的支持裝置包括獲取模塊，用于獲取來自于正在通話的 終端的消息，其中，消息攜帶有補充業(yè)務的申請信息，通話處于本地交換模式；模式轉換模 塊，用于根據申請信息將通話從本地交換模式轉換為通信數據經由核心網傳送的傳統(tǒng)通話 模式；轉發(fā)模塊，用于將消息轉發(fā)至核心網。優(yōu)選地，上述裝置還包括存儲模塊，用于將消息進行存儲。優(yōu)選地，上述裝置還包括構造模塊，用于在基站控制器將通話從本地交換模式轉 換傳統(tǒng)通話模式失敗時，構造補充業(yè)務拒絕消息并發(fā)送至終端。通過本發(fā)明，在本地交換模式下的通話中，及時捕獲特征后、及時調整通話模式到 傳統(tǒng)通話模式下，進而可以彌補在本地交換技術下對補充業(yè)務處理的不足，使用戶在本地 交換模式下依舊可以使用補充業(yè)務，提高了用戶感知度和運營商信任度。
此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā) 明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中圖1為根據本發(fā)明實施例的補充業(yè)務的支持方法的流程圖；圖2為根據本發(fā)明實施例的通話中接收補充業(yè)務請求的處理流程圖；圖3為根據本發(fā)明實施例的終端再次申請補充業(yè)務時的處理流程圖；圖4為根據本發(fā)明實施例的補充業(yè)務通話存在標識的示意圖；圖5為根據本發(fā)明實施例的補充業(yè)務結束時的判斷處理流程圖；圖6為根據本發(fā)明實施例的核心網接收到基站控制器轉發(fā)的補充業(yè)務申請信息 后的處理流程圖；圖7為根據本發(fā)明實施例的另一補充業(yè)務的支持方法的流程圖；圖8為根據本發(fā)明優(yōu)選實施例的另一補充業(yè)務的支持方法的流程圖；圖9為根據本發(fā)明實施例的補充業(yè)務的支持裝置的結構框圖；圖10為根據本發(fā)明優(yōu)選實施例的補充業(yè)務的支持裝置的結構框圖；圖11為根據本發(fā)明實例的補充業(yè)務的支持裝置的工作方式示意圖；圖12為根據本發(fā)明實施例的另一補充業(yè)務的支持裝置的結構框圖。
具體實施例方式下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的 情況下，本申請中的實施例及實施例中的特征可以相互組合。根據本發(fā)明實施例，提供了 一種補充業(yè)務的支持方法。圖1為根據本發(fā)明實施例的補充業(yè)務的支持方法的流程圖。如圖1所示，根據本 發(fā)明實施例的補充業(yè)務的支持方法包括以下處理(步驟SlOl-步驟S105)步驟SlOl 在通話處于本地交換模式時，基站控制器獲取來自于正在通話的終端的消息，其中，消息攜帶有補充業(yè)務的申請信息；步驟S103 基站控制器根據申請信息將通話從本地交換模式轉換為通信數據經 由核心網傳送的傳統(tǒng)通話模式；步驟S105 基站控制器將消息上報至核心網。該實施例中的補充業(yè)務的支持方法，可以彌補在本地交換技術下對補充業(yè)務處理 的不足，使用戶在本地交換模式下依舊可以使用補充業(yè)務(例如，呼叫保持或呼叫等待)， 可以提高用戶感知度和運營商信任度。優(yōu)選地，在執(zhí)行步驟S103之前，還可以包括以下處理基站控制器將消息進行存儲。在本地交換模式下，用戶申請補充業(yè)務時，需要先轉換到傳統(tǒng)模式下才能進行，因 此，用戶申請的命令可以不立刻上報給核心網，將該消息暫存下來，待模式轉換完成時，再 次轉發(fā)給核心網。優(yōu)選地，在執(zhí)行步驟103時，如果基站控制器將通話從本地交換模式轉換為傳統(tǒng) 通話模式時失敗了，則基站控制器需要構造補充業(yè)務拒絕消息，并發(fā)送至終端。在具體實施過程中，在模式轉換失敗的時候，將存儲的用戶申請補充業(yè)務的消息 上報給核心網已經沒有意義，因為用戶的語音數據在本地交換模式下，無法應用核心網功 能，所以一旦申請消息轉發(fā)到核心網，接收到核心網的確認消息后，卻沒法實施，反而會造 成異常。于是，在發(fā)現模式轉換失敗后，基站控制器直接構造補充業(yè)務拒絕消息回復手機， 避免手機不斷發(fā)起補充業(yè)務請求。以下結合圖2描述上述過程。圖2為根據本發(fā)明實施例的通話中接收補充業(yè)務請 求的處理流程圖。如圖2所示，該流程包括以下處理(步驟S201-步驟S215)步驟S201 通話期間接收到終端發(fā)起的直接傳送應用部分(Direct Transfer Application Part，簡稱為DTAP)消息時，獲知并判斷為補充業(yè)務申請消息(呼叫保持) 時，查詢原通話當前模式狀態(tài)標識。如果標識表明原通話當前為本地交換模式，則進入步驟 S203。如果是傳統(tǒng)交換模式(即傳統(tǒng)通話模式)，則進入步驟S215。如果獲知并判斷為拆 鏈消息，清除允許本地交換轉換標識、清除補充業(yè)務拒絕標識、清除本通話存在標識，之后 轉入步驟S215。其中，上述標識是運營商預先設置的，可以通過標識的設置和判斷，在執(zhí)行后續(xù)流 程時可以簡化流程。上述允許本地交換轉換標識的狀態(tài)，用于表示是否允許進行本地交換 模式的轉換；上述補充業(yè)務拒絕標識的狀態(tài)，用于表示是否支持補充業(yè)務；上述本通話存 在標識的狀態(tài)，用于表示相應通話是否存在。步驟S203 當發(fā)現當前模式狀態(tài)為本地交換模式時，則將該消息存儲在緩存區(qū)中。步驟S205 完成存儲工作后，發(fā)起向本地交換轉換流程。步驟S207 在轉換成功時，返回模式轉換成功消息?；蚴窃谵D換失敗時，返回模式 轉換失敗消息。步驟S209 接收到模式轉換成功消息時，將存儲的消息，轉發(fā)給核心網，流程結 束?；蛘?，當接收到模式轉換失敗消息時，進行補充業(yè)務拒絕消息的構造。步驟S211 構造補充業(yè)務拒絕消息；
步驟S213 將補充業(yè)務拒絕消息轉發(fā)給終端，并置補充業(yè)務拒絕標識為是。流程結束。步驟S215 基站控制器直接將消息透傳給核心網。優(yōu)選地，在執(zhí)行步驟105之后，還可以包括以下處理(1)當核心網無法支持補充業(yè)務時，基站控制器對無法支持的狀態(tài)進行標識；(2)當再次接收攜帶有申請信息的消息時，基站控制器根據標識將不會把消息上 報至核心網。由于核心網不支持補充業(yè)務，因此將核心網對補充業(yè)務的拒絕情況記錄在相關標 識中，之后，如果用戶再次發(fā)起通話期間的補充業(yè)務，是否直接拒絕、不再傳送給核心網，需 要根據用戶預設標識進行判斷。通過設置上述標識，可以簡化后續(xù)流程，節(jié)省系統(tǒng)資源。優(yōu)選地，在執(zhí)行步驟105之后，還可以包括以下處理(1)當核心網支持補充業(yè)務時，基站控制器獲取并解析終端與核心網傳輸的信 息；(2)基站控制器根據信息確定補充業(yè)務已經結束；(3)基站控制器繼續(xù)將當前通話保持在傳統(tǒng)通話模式下，或者，在預設的補充業(yè)務 結束處理標識為是的情況下，將當前通話從傳統(tǒng)通話模式轉換至本地交換模式下。在具體實施過程中，當終端的兩個通話之一結束時，終端的通話是否從傳統(tǒng)通話 模式再次回到本地交換模式下。顯然，只處理終端原通話還存在的這種情況(其中，原通話 是在進行模式轉換之前，處于本地交換模式下的通話)?，F在，這種情況下，還可以將模式轉 換回本地交換模式，如果用戶再次申請補充業(yè)務，則會帶來頻繁的模式轉換，但是，卻可以 最大限度節(jié)約Abis 口資源。因此，是否需要預設補充業(yè)務結束處理標識，可以由運營商決 定。以下結合圖3描述上述處理過程，如圖3所示，該過程主要包括以下處理(步驟 S301-步驟 S313)步驟S301 在通話中，終端發(fā)起補充業(yè)務申請消息(呼叫保持或呼叫恢復)。步驟S303 基站控制器判斷出是補充業(yè)務申請消息(第一次申請一定是呼叫保持 消息)。步驟S305 檢查預設拒絕處理消息標識，如果標識為是，則執(zhí)行步驟S307，當用戶 預設處理拒絕消息標識為否時，當終端發(fā)起補充業(yè)務申請，不再考慮補充業(yè)務拒絕處理標 識情況，執(zhí)行步驟S311。其中，如果拒絕處理消息標識是運營商預設的，則在收到核心網的補充業(yè)務拒絕 消息后設置補充業(yè)務拒絕處理標識。當標識為是時，說明運營商認為核心網既然發(fā)送補充 業(yè)務拒絕消息，就說明當前配置不支持，就不用再不斷發(fā)起模式轉換了，用戶再次申請補充 業(yè)務時，可以直接拒絕；而當預設拒絕處理消息標識為否時，說明運營商雖然認為核心網發(fā) 送了補充業(yè)務拒絕消息，但是仍然希望用戶不斷嘗試、最大限度地獲得機會。步驟S307 當用戶預設處理拒絕消息標識為是時，當終端再次發(fā)送補充業(yè)務申 請，當補充業(yè)務拒絕處理標識為是時，執(zhí)行步驟S309，否則，執(zhí)行步驟S311。步驟S309 當基站控制器判別核心網不支持補充業(yè)務時，可以給終端發(fā)送補充業(yè) 務拒絕消息，避免發(fā)起頻繁的模式轉換。
步驟S311 補充業(yè)務拒絕處理標識為否時，表明可能是第一次申請補充業(yè)務或者 核心網的確支持補充業(yè)務，因此，結合當前模式狀態(tài)標識情況進行判斷。在當前模式狀態(tài)標 識為本地交換時，將消息進行存儲、并標識記錄、在模式轉換成功后轉發(fā)消息給核心網。步驟S313 在當前模式狀態(tài)標識為傳統(tǒng)通話模式時，則直接透傳給核心網。優(yōu)選地，上述步驟(3)中將當前通話從傳統(tǒng)通話模式轉換至本地交換模式下可以 進一步包括(3. 1)基站控制器根據設置的通話標識，判斷當前通話是否為原通話，其中，原通 話為本地交換模式下的通話；(3. 2)在當前通話為原通話的情況下，基站控制器將當前通話從傳統(tǒng)通話模式轉 換至本地交換模式下。其中，上述原通話為步驟SlOl中提到的正在進行的通話，相對地，新通話為進行 呼叫保持或呼叫等待時第二次接通的通話?？蓪υㄔ捄托峦ㄔ挼拇嬖谠O置標識，具體可 以參見圖3。圖4為根據本發(fā)明實施例的補充業(yè)務通話存在標識的示意圖。如圖4所示，采用 原通話存在標識表示終端第一次建立通話的通話狀態(tài)，采用新通話存在標識表示終端第二 次建立通話的通話狀態(tài)。具體含義可以參見表1。表 權利要求
1.一種補充業(yè)務的支持方法，其特征在于，在通話處于本地交換模式時，所述方法包括基站控制器獲取來自于正在通話的終端的消息，其中，所述消息攜帶有補充業(yè)務的申 請信息；所述基站控制器根據所述申請信息將所述通話從本地交換模式轉換為通信數據經由 核心網傳送的傳統(tǒng)通話模式；所述基站控制器將所述消息上報至所述核心網。
2.根據權利要求1所述的方法，其特征在于，在所述基站控制器根據所述申請信息將 所述終端從本地交換模式轉換為傳統(tǒng)通話模式之前，所述方法還包括所述基站控制器將所述消息進行存儲。
3.根據權利要求1所述的方法，其特征在于，在所述基站控制器將所述通話從本地交 換模式轉換傳統(tǒng)通話模式失敗時，所述方法還包括所述基站控制器構造補充業(yè)務拒絕消息，并發(fā)送至所述終端。
4.根據權利要求1至3中任一項所述的方法，其特征在于，在所述基站控制器將所述消 息上報至所述核心網之后，所述方法還包括當所述核心網無法支持所述補充業(yè)務時，所述基站控制器對無法支持的狀態(tài)進行標識；當再次接收攜帶有所述申請信息的消息時，所述基站控制器根據所述標識拒絕將所述 消息上報至所述核心網。
5.根據權利要求1至3中任一項所述的方法，其特征在于，在所述基站控制器將所述消 息上報至所述核心網之后，所述方法還包括當所述核心網支持所述補充業(yè)務時，所述基站控制器獲取并解析所述終端與所述核心 網傳輸的信息；所述基站控制器根據所述信息確定所述補充業(yè)務已經結束；所述基站控制器繼續(xù)將當前通話保持在所述傳統(tǒng)通話模式下，或者，在預設的補充業(yè) 務結束處理標識為是的情況下，將所述當前通話從所述傳統(tǒng)通話模式轉換至所述本地交換 模式下。
6.根據權利要求5所述的方法，其特征在于，將所述當前通話從所述傳統(tǒng)通話模式轉 換至所述本地交換模式下包括所述基站控制器根據設置的通話存在標識，判斷所述當前存在的通話是否為原通話， 其中，所述原通話為本地交換模式下的通話；在所述當前通話為原通話的情況下，所述基站控制器將所述當前通話從所述傳統(tǒng)通話 模式轉換至所述本地交換模式下。
7.一種補充業(yè)務的支持方法，其特征在于，在通話處于通信數據經由核心網傳送的傳 統(tǒng)通話模式時，所述方法包括基站控制器將呼叫方的標識信息與預設標識信息進行比較，確定是否一致； 在所述呼叫方的標識信息與所述預設標識信息一致的情況下，所述基站控制器禁止發(fā) 起本地交換模式的轉換。
8.根據權利要求7所述的方法，其特征在于，在禁止發(fā)起本地交換模式的轉換之后，所述方法還包括所述基站控制器判斷預設的允許本地交換標識的狀態(tài)；所述基站控制器根據所述允許本地交換標識的狀態(tài)確定是否進行模式轉換。
9.一種補充業(yè)務的支持方法，其特征在于，在通話處于通信數據經由核心網傳送的傳 統(tǒng)通話模式時，所述方法包括基站控制器在獲取電話接通的指示信息之前，禁止發(fā)起本地交換模式的轉換。
10.一種補充業(yè)務的支持裝置，其特征在于，所述裝置包括獲取模塊，用于獲取來自于正在通話的終端的消息，其中，所述消息攜帶有補充業(yè)務的 申請信息，所述通話處于本地交換模式；模式轉換模塊，用于根據所述申請信息將所述通話從本地交換模式轉換為通信數據經 由核心網傳送的傳統(tǒng)通話模式；轉發(fā)模塊，用于將所述消息轉發(fā)至所述核心網。
11.根據權利要求10所述的裝置，其特征在于，所述裝置還包括 存儲模塊，用于將所述消息進行存儲。
12.根據權利要求10所述的裝置，其特征在于，所述裝置還包括構造模塊，用于在所述基站控制器將所述通話從本地交換模式轉換傳統(tǒng)通話模式失敗 時，構造補充業(yè)務拒絕消息并發(fā)送至所述終端。
全文摘要
本發(fā)明公開了一種補充業(yè)務的支持方法及裝置，在通話處于本地交換模式時，基站控制器獲取來自于正在通話的終端的消息，其中，該消息攜帶有補充業(yè)務的申請信息；基站控制器根據申請信息將通話從本地交換模式轉換為通信數據經由核心網傳送的傳統(tǒng)通話模式；基站控制器將消息上報至核心網。根據本發(fā)明提供的技術方案，可以彌補在本地交換技術下對補充業(yè)務處理的不足，使用戶在本地交換模式下依舊可以使用補充業(yè)務，提高了用戶感知度和運營商信任度。
文檔編號H04W4/16GK102123364SQ20101000360
公開日2011年7月13日 申請日期2010年1月7日 優(yōu)先權日2010年1月7日
發(fā)明者劉強 申請人:中興通訊股份有限公司