CN101288320A - 承载路径建立、优化方法及装置 - Google Patents

承载路径建立、优化方法及装置 Download PDF

Info

Publication number
CN101288320A
CN101288320A CNA2006800065762A CN200680006576A CN101288320A CN 101288320 A CN101288320 A CN 101288320A CN A2006800065762 A CNA2006800065762 A CN A2006800065762A CN 200680006576 A CN200680006576 A CN 200680006576A CN 101288320 A CN101288320 A CN 101288320A
Authority
CN
China
Prior art keywords
calling
access device
wmg
callee
end points
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2006800065762A
Other languages
English (en)
Other versions
CN101288320B (zh
Inventor
尤昉
刘文宇
徐杰
李云飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CNA2005101240588A external-priority patent/CN1870824A/zh
Priority claimed from CNA2005101215232A external-priority patent/CN1874544A/zh
Priority claimed from CNA2006100331762A external-priority patent/CN1874601A/zh
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN200680006576.2A priority Critical patent/CN101288320B/zh
Priority claimed from PCT/CN2006/002688 external-priority patent/WO2007041963A1/zh
Publication of CN101288320A publication Critical patent/CN101288320A/zh
Application granted granted Critical
Publication of CN101288320B publication Critical patent/CN101288320B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明公开了一种承载路径建立、优化方法及装置,该方法包括:判断承载路径中对应媒体网关两侧承载连接端点的数据编码格式是否相同,若所述媒体网关两侧承载连接端点的数据编码格式相同,则从所述承载路径中删除该媒体网关,并更新与该媒体网关相邻的承载连接端点的承载参数。另外还提供相应的承载路径管理装置。本发明将相应的媒体网关从所述承载路径中删除,并更新与该媒体网关相邻的承载连接端点的承载参数,或直接在呼叫侧接入设备与被叫侧接入设备之间建立承载路径,以优化承载路径,并在承载路径更新后释放媒体网关的承载资源,从而减少媒体数据流的中间处理环节,而且节省媒体网关的承载资源,因而提高网络整体效率和性能。

Description

承载路径建立、 优化方法及装置
技术领域
本发明涉及移动通信技术领域, 具体涉及承载控制分离架构下的承 载路径建立、 优化方法及装置。 背景技术
移动通信网络正在向全 IP网络演进, 目前, 在电路域网络已经引入 了^载和控制分离的架构, 原来的移动交换中心 (MSC )分成移动软交 换(MSCe )和媒体网关 (MGW, Media Gateway ) 两个设备, 分别用于 信令控制和承载处理。 另外, A接口 IP化之后, 基站(BS, Base Station ) 和 MSCe之间的 Alp接口信令以及 BS和 MGW之间的 A2p接口数据均 承载在 IP网络上, 相关功能实体的网络位置和接口连接关系, 如图 1所 示, MGW还与公共交换电话网( PSTN, Public Switch Telephone Network ) 相连接。 根据现有协议, A2p不仅提供 BS与 MGW之间的承载路径, 基 站 BS之间的 IP承载路径也由 A2p提供。
移动交换中心与接入设备间的语音承载采用 IP后, MGW和接入设 备间的话路由 TDM电路承载改为 IP承载。 采用 IP建承载后, 接入设备 和 MGW分配各自的 IP地址和端口号, 通过 MSCe交互这两个实体的 IP 地址和端口号并建立承载。, 参见图 2所示, MGW和 BSC间的话路由 TDM电路承载改为 IP承载。 通过 MSCe的消息交互, BSC和 MGW知 道双方的 IP地址、 端口号、 编解码, 完成 MGW与 BSC间的承载建立。 承载建立后, 如果主叫侧接入设备与被叫侧接入设备的编解码能力不同 时, MGW进行编解码转换, 如果相同时, MGW不作任何转换, 将其 接收的媒体流直接透传。 但是, 当主叫侧接入设备(也可称为源接入设 备)和被叫侧接入设备(也可称为目标接入设备)的编解码能力相同时, MGW将其接收的媒体流直接透传会增加媒体流的中间处理环节, 占用 MGW的资源。
参见图 3所示, 局间采用 IP承载, 通过 SIP信令协商两端的 IP信息 建立承载,主叫局通过 ADD消息通知 MGW建 IP承载, MGW返回分配 的 IP端点信息, 主叫局在 INVITE消息中带本端 MGW的 IP端点信息, 支持的 CODEC列表; 被叫局通过 ADD消息通知 MGW建 IP承载(带 有主叫局 MGW分配的 IP端点信息:), MGW返回分配的 IP端点信息, 被叫局在 180或 200消息带本端 MGW的 IP端点信息, 选择的 CODEC; 主叫局 MSCe通过 MODIFY消息把被叫局 MGW的 IP端点信息通知本端 MGW, 建立 IP承载。
图 4 以一个典型的局间呼叫流程为例对现有的技术方案进亍描述, 方便起见, 假设主叫侧 BS 的 A2p 承载参数在连接管理业务请求 ( Connection Management Service Request )消息中传给主叫側 MSCe, 被 叫侧 BS的 A2p承载参数在 Paging Response (寻呼响应) 消息中传给被 叫侧 MSCe, 回铃音由被叫局提供, 消息流程中省略了与归属位置寄存器 ( HLR ) 交互被叫路由的过程。 具体呼叫建立流程如下:
1、 MSCel收到 BS1发送的 CM Service Request消息, 其中携带 A2p 承载参数, 主要包括 BS1侧期望的编码格式列表, BS1上承载连接端点 的 IP地址, 端口号;
2、 MSCel下发 ADD (增加)消息到 MGW1 ,请求分配两个 RTP (实 时传输协议)类型端点, 分别对应 BS1侧和被叫侧的承载连接端点;
3、 MSCel收到 MGW1返回的 REPLY (应答)消息, 其中携带申请 好的两个 RTP端点的会话描述协议 ( SDP, Session Descriptor Protocol ) 信息,分别主要包括 MGW1支持的编码格式、各端点的 IP地址及端口号;
4、 MSCel发送 INVITE (请求) 消息到 MSCel , 携带 MGW1对应 被叫侧的 RTP端点的 SDP;
5、 MSCel发送 Assignment Request (指配请求) 消息到 BS1请求分 配空口资源, 携带 MGW1对应 BS1侧的 RTP端点的 A2p承载参数; 6、 空口资源建立完成后, MSCel 收到 BS1 发送的 Assignment
Complete (指配完成) 消息;
7、 找到被叫所在位置后 , MSCe2发送 Paging Request (寻呼请求) 消息到 BS2, 可以携带从主叫侧得到的编码格式列表;
8、 MSCe2收到 BS2返回的 Paging Response消息, 其中携带 BS2侧 的 A2p参数, 包括 BS2侧接受的编码格式, BS2上^^载连接端点的 IP地 址, 端口号;
9、 MSCe2下发 ADD消息到 MGW2, 请求分配两个 RTP类型端点, 分别对应 BS2侧和主叫侧的 ^载连接端点;
10、 MSCe2收到 MGW2返回的 REPLY消息, 其中携带申请好的两 个 RTP端点的 SDP信息, 分别主要包括 MGW2支持的编码格式, 各自 端点的 IP地址, 端口号;
11、 MSCe2发送 Assignment Request消息到 BS2请求分配空口资源, 携带 MGW2对应 BS2侧的 RTP端点的 A2p承载参数;
12、 空口资源建立完成后, MSCe2 收到 BS2 发送的 Assignment
Complete消息;
13、 MSCel收到 MSCe2返回的 180消息, 其中携带 MGW2上对应 主叫侧端点的 SDP;
14、 MSCe2下发 MODIFY (修改)消息到 MGW2, 请求对靠近主叫 侧的 RTP端点放回铃音;
15、 MSCe2收到 MGW2返回的 REPLY消息;
16、 MSCel发送 180的 PRACK (临时响应确认) 消息到 MSCe2;
17、 MSCel收到 MSCe2返回的 PRACK消息的 200 OK响应;
18、 MSCel下发 MODIFY消息到 MGW1 ,将其被叫侧端点的 Remote (远端) SDP更新为 180消息中带过来的 MGW2上靠近主叫侧端点的
SDP;
19、 MSCel收到 MGW1返回的 REPLY消息;
20、 MGW2到主叫用户的单向回铃音数据流建立;
21、 MSCe2收到 BS2的 Connect (连接 )消息, 指示被叫用户应答; 22、 MSCe2下发 MODIFY (修改)消息到 MGW2, 请求对靠近主叫 侧的 RTP端点停止播放回铃音;
23、 MSCe2收到 MGW2返回的 REPLY消息;
24、 MSCel收到 MSCe2返回的 INVITE消息的 200 OK响应;
25、 MSCel下发 MODIFY消息到 MGW1, 将被叫侧端点的媒体流 属性修改为双向;
26、 MSCel收到 MGW1返回的 REPLY消息;
27、 MSCel返回 ACK (确认) 消息到 MSCe2;
28、 主被叫用户之间双向承载通道建立完成;
29、通话结束后,被叫用户挂机, MSCe2收到 BS2发送的 Clear Request
(清除请求) 消息;
30、 MSCe2发送 Clear Command (清除命令) 消息到 BS2;
31、 MSCel收到 MSCe2发送的 BYE (拆线) 消息;
32、 MSCel发送 Clear Command消息到 BS1;
33、 MSCel收到 BS1返回的 Clear Complete消息;
34、 MSCel发送 BYE的 200 OK响应消息到 MSCe2;
35、 MSCel下发 SUBSTRACT (删除)消息到 MGW1 , 释放本次呼 叫占用的 RTP端点;
36、 MSCel收到 MGW1返回的 REPLY消息;
37、 MSCe2收到 BS2返回的 Clear Complete消息;
38、 MSCe2下发 SUBSTRACT消息到 MGW2,释放本次呼叫占用的 RTP端点;
39、 MSCe2收到 MGW2返回的 REPLY消息。
目前电路域网络承载和控制分离且接入网与核心网间接口 IP化的网 络架构中 , MGW 在网 内除了具备放音, DTMF ( Dual Tone Multi-Frequency, 双音多频)检测上报, 插入会议资源等媒体资源操作功 能外, 另外一个重要作用是进行编解码格式的转换。 可以注意到, 在 IP 化后的电路域网絡内部, MGW用于编解码格式转换的功能在逐渐弱化, 特别是以提高语音质量, 减少编解码转换过程为目的的免编解码操作 ( TrFO, Transcoder Free Operation )和远端编解码操作 ( RTO, Remote Transcoder Operation )功能的支持和应用, 更加速了这种趋势。 如图 5所 示, TrFO是指在分组传输网络内部, 如果利用带外信令协商得到呼叫两 端相同的编解码类型, 则不需要进行语音编解码, 直接从端到端传送压 缩语音。 RTO是指在不能得到两端相同的编解码格式的情况下, 仅进行 一次编解码转换。 协议规定, 在先后尝试了 TrFO和 RTO后仍无法使两 端编码格式匹配, 才使用两个编解码器, 将两端格式都转换为通用传输 格式(如 G.711 )进行互通。 图 5中 EVRC ( Enhanced Variable Rate Code ) 为增强可变速率编解码格式, 假设编解码器 (TC, TransCoder )存在于 MGW上。
从上述呼叫流程可以看出, 在呼叫过程中, 即使呼叫两端已经协商 到相同的编码格式(不需要 MGW提供 TC功能), 或者使用小于 MGW 数目的 TC就能完成编解码格式转换的情况下,所有 MGW也始终存在于 承载路径中, MGW上的端点直到呼叫释放时才能够释放。
目前 BS 已经支持 IP接口, 但在现有技术中, 即使处在分组传输网 絡内部的呼叫两端使用相同的编码格式(TrFO ), 通话过程中承载路径仍 必然通过 MGW, 增加了数据包的延时, 不利于语音质量的提高, 随着目 前越来越多的运营商倾向于网内使用统一编码格式, 该缺点也越来越明 显。
大部分普通呼叫在对主叫放回铃音后都进入稳定的 (也可能是长时 间的)双向通话过程中, 两端使用相同的编码格式或者使用 TC数目小于 途经的 MGW数目时,在整个呼叫过程中承载经过不必要的 MGW, 必然 造成 MGW上资源 (RTP端点) 的浪费。
使用相同编码格式的主被叫在同一 BS下通话时,承载经过 MGW容 易造成路由迂回, 浪费 IP传输资源。 发明内容
本发明的目的是提供承载路径建立、 优化方法及装置, 以减少路由 迂回, 提高资源利用率。
根据本发明提供的一种承载路径优化方法, 包括:
主叫用户呼叫被叫用户, 建立本次呼叫的承载路径后, 判断承载路 径中对应媒体网关两侧承载连接端点的数据编码格式是否相同,
若所述媒体网关两侧承载连接端点的数据编码格式相同, 则将该媒 体网关从所述承载路径中删除, 并更新与该媒体网关相邻的承载连接端 点的承载参数。 当所述呼叫为同一个交换局内的呼叫 , 判断出对应媒体网关两侧承 载连接端点的数据编码格式相同, 则将该媒体网关从所述承载路径中删 除, 更新主叫侧或 /和被叫侧接入网设备对应网络侧的承载连接端点的承 载参数, 使主叫侧与被叫侧接入网设备之间承载直接互连。
当所述呼叫为交换局间呼叫, 当主叫侧或 /和被叫侧媒体网关两侧承 载连接端点的数据编码格式相同, 则将相应的主叫侧或 /和被叫侧媒体网 关从承载路径中删除, 并更新相关网络侧的承载连接端点的承载参数。
当被叫侧媒体网关两侧承载连接端点的数据编码格式相同, 主叫侧 媒体网关两侧承载连接端点的数据编码格式不同, 则将被叫侧媒体网关 从承载路径中删除, 更新被叫对应网络侧的承载连接端点和主叫媒体网 关对应被叫侧的承载连接端点的承载参数, 使被叫侧接入网设备与主叫 侧媒体网关之间承载直接互连。
若被叫侧和主叫侧对应媒体网关两侧承载连接端点的数据编码格式 相同 , 则将被叫侧媒体网关和主叫侧媒体网关分别从承载路径中删除, 更新主叫和被叫对应网络侧的承载连接端点的承载参数, 使使主叫和被 叫接入网设备之间承载直接互连。
所述呼叫为经过汇接局的交换局间呼叫, 局间承载路径建立后, 判 断所述承载路径上的中间媒体网关两侧承载连接端点的数据编码格式是 否相同, 若相同, 则将该中间媒体网关从承载路径中删除;
向所述中间媒体网关对应的移动软交换发送更新请求消息。
所述更新请求消息由上一级媒体网关对应的移动软交换传送到下一 级媒体网关对应的移动软交换;
各级移动软交换分别判断其对应的媒体网关两侧端点的数据编码格 式是否相同, 若相同, 则在承载路径中删除对应的媒体网关。
优选地, 该方法还包括:
在承载路径建立前, 比较主、 被叫侧接入设备的编解码能力, 若存 在相同的编解码能力, 则在主叫侧接入设备与被叫侧接入设备间直接建 立 载连接, 并建立主叫侧接入设备和媒体网关间的放音通道; 否则, 通过网络侧的媒体网关建立主、 被叫侧接入设备间的承载连接; 所述承载连接包括: 主叫侧接入设备与被叫侧接入设备间直接建立 语音通道, 以及主叫侧接入设备与媒体网关间建立的放音通道。
根据本发明还提供一种承载路径管理装置, 通常设置在局端设备中 , 包括:
承载建立模块, 用于获取呼叫侧接入设备和被叫侧接入设备信息并 控制呼叫侧接入设备、 被叫侧接入设备以及媒体网关之间建立承载; 判断模块, 用于比较判断呼叫侧接入设备与被叫侧接入设备的编解 码能力是否相同和 /或判断媒体网关两侧承载连接端点的数据编码格式是 否相同, 并将判断结果信息发送给承载更新模块;
承载更新模块, 根据判断模块的判断结果信息控制呼叫侧接入设备 与被叫侧接入设备之间承载路径调整。
该装置还包括:
资源管理模块, 根据所述承载路径调整信息控制相应媒体网关释放 与源接入设备及被叫侧接入设备之间建立的承载资源。
更适宜地, 当所述判断模块判断承载路径中的媒体网关两侧承载连 接端点的数据编码格式相同, 则承载更新模块将该媒体网关从所述承载 路径中删除, 并更新与该媒体网关相邻的承载连接端点的相关参数。
更适宜地, 当所述判断模块判断呼叫侧接入设备与被叫侧接入设备 的编码能力相同, 承载更新模块分别向呼叫侧接入设备发送被叫侧接入 设备的端点信息, 以及向被叫侧接入设备发送源接入设备的端点信息, 并控制主叫侧接入设备与被叫侧接入设备之间直接建立承载。
根据本发明的另一方面, 提供一种呼叫接续的方法, 包括下列步骤: 对主被叫侧接入设备的编解码能力列表进行对比, 若存在相同的编 解码, 则直接建立主被叫侧接入设备间的承载;
否则, 通过网络侧的媒体网关 MGW建立主被叫侧接入设备间的承 载。
所述直接建立主被叫侧接入设备间的承载包括: 建立主被叫侧接入 设备间的语音通道, 以及建立 MGW与接入设备间放音通道。
所述主被叫侧接入设备在同一 MSCe覆盖范围内, 由 MSCe比较主 被叫侧接入设备的编解码能力列表。
优选地, 存在相同的编解码能力时, 所述 MSCe在发给主叫侧接入设 备的承载信息中携带被叫侧接入设备的 IP端点信息和主被叫侧接入设备 共同支持的编解码能力, 以建立语音通道,并携带 MGW的 IP端点信息, 以建立放音通道。
优选地, 存在相同的编解码能力时, 所述 MSCe在发给被叫侧接入 设备的承载信息中携带主叫侧接入设备的 IP端点信息和主被叫侧接入设 备共同支持的编解码能力, 以建立语音通道。
优选地, 所述删除主叫侧接入设备与 MGW之间的放音通道后, 包 括下列步骤:
主叫侧 MSCe释放主叫侧 MGW上的 IP端点资源;
主叫侧 MSCe通知被叫侧 MSCe释放放音通道;
被叫侧 MSCe释放被叫侧 MGW上的 IP端点资源。
根据本发明的又一方面, 提供一种实现局间切换的方法, 包括: 当移动台从源局切换至目标局时, 源侧移动交换中心根据源侧基站 的切换请求,要求源侧媒体网关分配第一 IP端点, 并将该第一 IP端点的 信息和源局提供的编解码列表发送至目标侧移动交换中心;
目标侧移动交换中心在目标侧基站的 IP端点与所述第一 IP端点之 间直接建立 IP承载。
综上所述, 本发明在承载路径中媒体网关两侧承载连接端点的数据 编码格式相同的情况下, 将相应的媒体网关从所述承载路径中删除, 并 更新与该媒体网关相邻的承载连接端点的承载参数, 或在呼叫侧接入设 备与被叫侧接入设备的编解码格式相同的情况下, 直接在呼叫侧接入设 备与被叫侧接入设备之间建立承载路径, 以优化承载路径, 并在承载路 径更新后释放媒体网关的承载资源, 从而减少媒体数据流的中间处理环 节, 而且节省媒体网关的承载资源, 因而提高网络整体效率和性能。
随着移动通信网向全 IP网络不断演进, 越来越多的运营商倾向于使 用统一的编码格式, 呼叫两端能够协商到相同编码格式的可能性越来越 大,通过采用本发明的承载路径优化,避免用户数据经过不必要的 MGW, 可以有效降低网络负荷, 减少数据包时延, 改善通话质量, 减少在长时 间通话过程中 MGW上资源的占用, 减少路由迂回的可能性。 附图说明
图 1为现有技术中控制承载分离架构, 接入网与核心网间接口 IP化 的网络实体连接示意图;
图 2为现有技术中 A口 IP化后话路承载示意图;
图 3为现有技术中局间 IP承载示意图;
图 4为现有技术中局间呼叫信令流程图;
图 5为现有技术中媒体网关提供数据编码格式转换功能示意图; 图 6为本发明的具体实施例中的方法流程示意图;
图 7为本发明的另一实施例中的方法流程示意图;
图 8为本发明的又一实施例中的方法流程示意图;
图 9为根据本发明的实施例中呼叫通过汇接局时的方法流程示意图; 图 10 为根据本发明的承载更新后够进行承载路径优化的方法流程 图;
图 11为根据本发明进行承载路径优化后重新启用媒体网关进行业务 处理的信令流程图;
图 12为根据本发明在呼叫接续过程中进行承载路径优化的方法流程 图;
图 13为本发明的优选实施例中局间 IP承载下建立双通道的架构示意 图;
图 14为根据本发明的局间 IP承载下的呼叫建立信令流程图; 图 15为根据本发明的端到端承载路径优化的方法流程图; 图 16是根据本发明实现用户的局间切换时的承载路径更新的方法流 出图;
图 17为本发明的实施例中承载路径管理装置架构示意图。 具体实施方式
本发明应用于承载控制分离架构下接入网与核心网间接口 IP化后的 移动通信网络, 基本方法为: 当主被叫之间建立起双向用户数据承载路 径后, 由移动软交换判断承载路径中对应的媒体网关两侧承载连接端点 的数据编码格式是否相同, 若是, 则将该媒体网关从承载路径中删除, 并更新承载路径中与该媒体网关相邻的承载连接端点的承载参数。
在呼叫建立过程中通过媒体网关建承载, 而不直接让主、 被叫接入 网设备直接建承载, 主要是要通过媒体网关对主叫进行放音。
在呼叫建立后, 在多数情况下, 媒体网关不需要再对主叫进行放音, 如果两侧数据编码格式相同, 则媒体网关进行透传, 因此可以把媒体网 关从承载路径中删除。
为使本发明的原理、 特性和优点更加清楚, 下面分别根据不同的网 络间呼叫情况及需要删除的媒体网关情况对本发明予以说明。
实施例 1
主被叫属于同一个交换局内的呼叫。
对于局内呼叫, 当主被叫在同一个交换局内时, 情形比较简单; 当 被叫应答后, 若移动软交换判断出媒体网关(MGW ) 两侧承载连接端点 的数据编码格式相同, 即主叫接入侧数据编码格式和被叫接入侧数据编 码格式相同, 则将本局所控制 MGW从承载路径中删除, 更新主被叫所 属基站对应网络侧的承载连接端点的承载参数, 使主叫和被叫所属基站 之间承载直接互连。
实施例 2
主叫被属于同一个汇接局下的不同交换局内的呼叫, 删除被叫侧媒 体网关的情形。
参照图 6, 假设主叫接入侧数据编码格式为 EVRC, 媒体网关之间和 被叫接入侧的数据编码格式都为 13Κ,在这种情况下,删除被叫侧媒体网 关, 具体流程如下:
1、 MSCe2收到 BS2的 Connect消息 , 指示被叫用户应答;
2、 MSCe2判断出被叫媒体网关 MGW2两侧数据编码格式相同, 可 以删除 MGW2进行承载路径优化, 向 MSCel发送 UPDATE请求消息, 其中携带 BS2对应网络侧端点 7的 SDP信息;
3、 MSCel接收 BS2对应网络侧端点 7的 SDP信息, 判断主叫侧媒 体网关 MGWl两侧数据编码格式不同,说明不能进行删除 MSG1的承载 路径优化, 给 MSCe2返回 200 OK响应, 其中携带的仍为 MGW1对应被 叫侧端点 4的 SDP信息;
4、 MSCe2发送 Bearer Update Request消息到 BS2, 将 MGW1对应 被叫侧端点 4的 SDP信息转化为承载参数携带给 BS2;
5、 BS2根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号, 并返回 Bearer Update Response消息;
6、 MSCel收到 MSCe2返回的 INVITE消息的 200 OK响应;
7、 MSCel下发 MODIFY消息到 MGW1, 将 MGWl上被叫侧端点 4 的 RemoteSDP更新为 BS2对应网络侧的端点 Ί的 SDP信息;
8、 MSCel收到 MGW1返回的 REPLY消息;
9、 MSCe2发送 SUBSTRACT消息到 MGW2,释放 MGW2上为本次 呼叫分配的两个端点 5和 6;
10、 MSCe2收到 MGW2返回的 REPLY消息;
11、 MSCel返回 ACK给 MSCe2;
12、 主被叫用户之间双向承载通道建立完成;
13、通话结束后 ,被叫用户挂机, MSCe2收到 BS2发送的 Clear Request 消息;
14、 MSCe2发送 Clear Command消息到 BS2;
15、 MSCel收到 MSCe2发送的 BYE消息;
16、 MSCel发送 Clear Command消息到 BS1;
17、 MSCel收到 BS1返回的 Clear Complete消息;
18、 MSCel发送 BYE的 200 OK响应消息到 MSCe2;
19、 MSCel发送 SUBSTRACT消息到 MGWl , 释放 MGWl上为本 次呼叫分配的两个端点 3和 4;
20、 MSCel收到 MGW1返回的 REPLY消息;
21、 MSCe2收到 BS2返回的 Clear Complete消息。
通过上述流程描述可知, 在该流程中, 通过将主叫侧的 MGW1对应 被叫侧端点的 RemoteSDP更新为被叫 BS2对应网络侧的端点的 SDP信 息,并在被叫 BS2中将保存的对端地址信息更新为主叫侧的 MGW1对应 被叫侧端点的 SDP信息, 从主被叫建立的呼叫承载路径中删除被叫侧的 MGW, 实现承载路径优化。
实施例 3
主叫被属于同一个汇接局下的不同交换局内的呼叫, 删除主叫侧媒 体网关的情形。
参见图 7,假设主叫接入侧数据编码格式和媒体网关之间的数据编码 格式都为 EVRC, 被叫接入侧的数据编码格式为 13K, 在这种情况下, 删 除主叫侧媒体网关, 具体流程如下:
1、 MSCe2收到 BS2的 Connect消息, 指示被叫用户应答;
2、 判断出主叫侧 MGW1与被叫侧 MGW2之间的数据编码格式和被 叫接入侧的数据编码格式不相同,不能进行删除 MGW2的承载路径优化, 向 MSCel发送 UPDATE消息,其中携带被叫侧 MGW对应主叫侧端点 5 的 SDP信息;
3、 MSCel收到 UPDATE消息后, 获知网关之间的 :据编码格式, 并和主叫接入侧编码格式比较,发现两者相同,说明可以进行删除 MSG1 的承载路径优化,发送 200 OK for UPDATE消息到 MSCe2,其中携带 BS1 对应被叫侧的端点 2的 SDP信息;
4、 MSCe2下发 MODIFY消息到 MGW2, 将端点 5的 RemoteSDP 修改更新为 200 OK for UPDATE消息中携带的 BS 1对应被叫侧的端点 2 的 SDP信息;
5、 MSCe2收到 MGW2返回的 REPLY消息;
6、 MSCe2返回 INVITE的 200 OK响应;
7、 MSCel发送 ACK消息到 MSCe2;
8、 MSCel发送 Bearer Update Request消息到 BSl , 将 MGW2对应 主叫侧端点 5的 SDP信息转化为承载参数携带给 BS1 ;
9、 BS1根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号, 并返回 Bearer Update Response消息;
10、 MSCel发送 SUBSTRACT消息到 MGW1 , 释放 MGW1上为本 次呼叫分配的两个端点 3和 4;
11、 MSCel收到 MGW1返回的 REPLY消息;
12、 MSCel返回 ACK给 MSCe2;
13、 主被叫用户之间双向 7|c载通道建立完成;
14、通话结束后,被叫用户挂机, MSCe2收到 BS2发送的 Clear Request 消息;
15、 MSCe2发送 Clear Command消息到 BS2;
16、 MSCel收到 MSCe2发送的 BYE消息;
17、 MSCel发送 Clear Command消息到 BS1;
18、 MSCe 1收到 BS 1返回的 Clear Complete消息;
19、 MSCel发送 BYE的 200 OK响应消息到 MSCe2;
20、 MSCe2发送 SUBSTRACT消息到 MGW2,释放本次呼叫分配的 两个端点 5和 6;
21、 MSCe2收到 MGW2返回的 REPLY消息;
11、 MSCe2收到 BS2返回的 Clear Complete消息。
通过上述流程描述可知, 在该流程中, 通过将被叫侧的 MGW2对应 主叫侧端点的 RemoteSDP更新为主叫 BS1对应网络侧的端点的 SDP信 息,并在主叫 BS1中将保存的对端地址信息更新为被叫侧的 MGW2对应 主叫侧端点的 SDP信息, 从主被叫建立的呼叫承载路径中删除主叫侧的 MGW, 实现承载路径优化。
实施例 4:
主叫被属于同一个汇接局下的不同交换局内的呼叫, 同时删除被叫 侧和主叫侧媒体网关的情形。
参照图 8,假设主叫接入侧和被叫接入侧及 MGW之间的数据承载编 码格式均为 EVRC,在这种情况下,可以同时删除被叫侧和主叫侧媒体网 关, 具体流程如下:
1、 MSCe2收到 BS2的 Connect消息, 指示被叫用户应答;
2、 MSCe2判断出主叫侧 MGW与被叫侧 MGW之间的数据编码格式 和被叫接入侧的数据编码格式相同, 可以进行删除 MGW2的承载路径优 化, 向 MSCel发送 UPDATE (更新)请求消息, 其中携带 BS2对应网络 侧端点 7的 SDP信息;
3、 MSCel收到 UPDATE消息后, 判断主叫侧媒体网关 MGW1两侧 数据编码格式相同, 说明可以进行删除 MSG1 的承载路径优化, 则给 MSCe2返回 200 OK响应, 携带 BS1对应网络侧端点 2的 SDP信息;
4、 MSCel发送 Bearer Update Request (承载更新请求 )消息到 BS1 , 将 BS2对应网络侧的端点 7的 SDP信息转化为承载参数携带给 BS1;
5、 BS1根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号,并返回 Bearer Update Response (承载更新响应) 消息;
6、 MSCe2发送 Bearer Update Request消息到 BS2, 将 BS1对应网络 侧的端点 2的 SDP信息转化为承载参数带给 BS2;
7、 BS2根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号, 并返回 Bearer Update Response消息;
8、 MSCel收到 MSCe2返回的 INVITE消息的 200 OK响应;
9、 MSCel发送 SUBSTRACT消息到 MGW1 ,释放 MGW1上为本次 呼叫分配的两个端点 3和 4;
10、 MSCel收到 MGW1返回的 REPLY消息;
11、 MSCe2发送 SUBSTRACT消息到 MGW2, 释放 MGW2上为本 次呼叫分配的两个端点 5和 6;
12、 MSCe2收到 MGW2返回的 REPLY消息;
13、 MSCel返回 ACK给 MSCe2;
14、 主被叫用户之间双向^^载通道建立完成;
15、通话结束后,被叫用户挂机, MSCe2收到 BS2发送的 Clear Request 消息;
16、 MSCe2发送 Clear Command消息到 BS2;
17、 MSCel收到 MSCe2发送的 BYE消息;
18、 MSCel发送 Clear Command消息到 BS1 ;
19、 MSCel收到 BS1返回的 Clear Complete消息; 20、 MSCel发送 BYE的 200 OK响应消息到 MSCe2;
21、 MSCe2收到 BS2返回的 Clear Complete消息。
通过上述流程描述可知, 在该流程中, 分别通过在主叫侧和被叫侧 BS中保存对端 BS对应网缘侧端点的 IP地址和端口号信息, 从主被叫建 立的呼叫承载路径中删除主叫侧和被叫侧的 MGW, 实现承载路径优化。
实施例 5:
主叫、 被叫属于不同汇接局内的呼叫, 从承载路径中删除不提供媒 体格式转换功能的 MGW。
参照图 9,假设主叫接入侧, 主叫侧 MGW与汇接局所控 MGW之间 承载编码格式为 EVRC ( Enhanced Variable Rate Codec, 增强可变速率编 解码), 汇接局所控 MGW与被叫侧 MGW之间, 被叫接入侧的承载编码 格式为 13K语音, 后文提到的 TC指 MGW提供编解码转换功能的部件, MGW提供 TC说明 MGW两侧编码格式不相同。 具体流程如下:
1. MSCe3收到 BS3的 Connect消息, 指示被叫用户应答;
2. MSCe3判断所控制的 MGW3在呼叫路径中不提供 TC ( MGW3 在本呼叫中两侧端点编码格式相同:), 可以将 MGW3从呼叫路径中删除, 向 MSCe2发送 UPDATE (更新 )请求消息, 其中携带 BS3对应网络侧端 点 9的 SDP信息; 如果 MSCe3判断所控制的 MGW3在呼叫路径中提供 TC , 也同样发送 UPDATE消息给 MSCe2 , 其中携带 MGW3对应主叫侧 端点 7的 SDP信息;
3. MSCe2收到 UPDATE消息, 判断所控制的 MGW2提供了 TC, 则返回 UPDATE的 200 OK响应, 其中携带 MGW2对应被叫侧端点 6的 SDP信息; 一般地, 如果非主叫接入侧 MSCe收到 UPDATE消息, 则向 主叫侧下一个 MSCe发送 UPDATE消息, 如果 MSCe所控制的 MGW不 提供 TC , 即所控制的 MGW 可以从承载路径中删除, 则使用收到的 UPDATE中所携带的 SDP信息作为发出的 UPDATE消息中的 SDP;否则 发出的 UPDATE消息中携带所控制 MGW的主叫侧端点的 SDP, 并且返 回 UPDATE消息的 200 OK响应, 其中携带所控制 MGW对应被叫侧端 点的 SDP信息;主叫接入侧 MSCe收到 UPDATE消息,直接返回 200 OK SDP信息或 BS侧端点 SDP信息;
4. MSCe2下发 MODIFY消息到 MGW2 ,将 MGW2上被叫侧端点 6 的 RemoteSDP更新为 BS3对应网络侧的端点 9的 SDP信息;
5. MSCe2收到 MGW2返回的 REPLY消息;
6. MSCe2 向 MSCel 发送 UPDATE (更新)请求消息, 其中携带 MGW2对应主叫侧端点 5的 SDP信息;
7. MSC1收到 UPDATE消息,判断为主叫接入侧 MSCe且所控制的 MGW1在呼叫路径中不提供 TC, 则返回 UPDATE的 200 OK响应, 其中 携带 BS1对应被叫侧端点 2的 SDP信息;
8. MSCe2下发 MODIFY消息到 MGW2,将 MGW2上主叫侧端点 5 的 RemoteSDP更新为 BS1对应网络侧的端点 2的 SDP信息;
9. MSCe2收到 MGW2返回的 REPLY消息;
10. MSCe3向 MSCe2发送 INVITE请求的 200 OK响应消息; l l. MSCe2向 MSCel发送 INVITE请求的 200 OK响应消息;
12. MSCel向 MSCe2返回 ACK消息;
13. MSCe2向 MSCe3返回 ACK消息;
14. MSCe3发送 Bearer Update Request( 载更新请求)消息到 BS3 , 将 MGW2对应被叫侧端点 6的 SDP信息转化为承载参数带给 BS3;
15. BS3根据 Bearer Update Request消息中的承载参数更新自己保 存的对端^^载信息, 并返回 Bearer Update Response消息;
16. MSCel发送 Bearer Update Request消息到 BS1 , 将 MGW2对 应主叫侧端点 5的 SDP信息转化为承载参数带给 BS1;
17. BS1根据 Bearer Update Request消息中的承载参数更新自己保 存的对端 载信息, 并返回 Bearer Update Response消息;
18.主被叫用户之间双向承载通道建立完成;
19.通话结束后,被叫用户挂机, MSCe3收到 BS3发送的 Clear Request 消息;
20. MSCe3发送 Clear Command消息到 BS3; 21. MSCe2收到 MSCe3发送的 BYE消息;
22. MSCe2发送 BYE消息到 MSCel;
23. MSCel发送 Clear Command消息到 BS1;
24. MSCel收到 BS1返回的 Clear Complete消息;
25. MSCel发送 BYE的 200 OK响应消息到 MSCe2;
26. MSCe2发送 BYE的 200 OK响应消息到 MSCe3;
27. MSCe2发送 SUBSTRACT消息到 MGW2,释放 MGW2上为本次 呼叫分配的两个端点 5和 6;
28. MSCe2收到 MGW2返回的 REPLY消息;
29. MSCe3收到 BS3返回的 Clear Complete消息。
以呼叫经过一个控制媒体网关的汇接局为例,说明如何从承载路径中 删除不提供语音编解码器(TC ) 的 MGW。 实际应用中, 也可能经过多 个汇接局和多个中间媒体网关, 其信令控制原理类似, 其中的更新请求 消息 ( UPDATE )由上一级 MGW对应的移动软交换传送到下一级 MGW 对应的移动软交换; 各级移动软交换分别判断其对应的 MGW的两侧端 点的数据编码格式是否相同, 若是, 则在承载路径中删除对应的 MGW。
执行媒体网关删除后,若当前仍保留在承载路径中的承载连接端点的 相邻媒体网关已被删除, 则更新该承载连接端点的承载参数, 使主叫所 属基站、 承载路径中未被删除的媒体网关和被叫所属基站之间承载互连。
需要注意的是, 如果汇接局在呼叫过程中只进行信令汇接而不控制 媒体网关的话, 只透传来往的 UPDATE消息和 UPDATE消息的 200 OK 响应, 并不进行判断和其它操作。
实施例 6
参照图 10, 假设原来以建立的双向通话承载主叫接入侧数据编码格 式为 EVRC, 媒体网关之间的数据编码格式为 G.711 , 被叫接入侧的数据 编码格式为 13K,通话后发生了承载参数改变,主叫接入侧数据编码格式 变为 SMV ( Selectable Mode Vocoders ), 媒体网关之间的数据编码格式变 为 SMV, 被叫接入侧的数据编码格式仍为 13K:
1、 主被叫用户之间双向承载通道建立完成; 2, 3、 承载参数协商修改流程, 与现有技术相同;
4、 MSCel判断出主叫接入侧的数据编码格式和主叫侧 MGW与被叫 侧 MGW之间的数据编码格式相同, 可以进行删除 MGW1的承载路径优 化,给 MSCe2发送 re-I VITE消息,携带主叫侧 BS端点 2的 SDP信息; 5、 MSCe2收到 re-INVITE消息后, 获知网关之间的数据编码格式, 并和被叫接入侧编码格式比较,发现两者不同,说明不能进行删除 MGW2 的承载路径优化, 则发送 200 OK for re-INVITE消息到 MSCel , 其中携 带被叫侧 MGW2对应主叫侧的端点 5的 SDP信息;
6、 MSCel返回 ACK给 MSCe2;
7、 MSCel发送 Bearer Update Request (承载更新请求)消息到 BS 1 , 将 MGW2对应主叫侧端点 5的 SDP信息转化为承载参数带给 BS1;
8、 BS1根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 7 载信息 , 并返回 Bearer Update Response消息;
9、 MSCel发送 SUBSTRACT消息到 MGW1 , 释放本次呼叫分配的 两个端点 3和 4;
10、 MSCel收到 MGW1返回的 REPLY消息。
11、 MSCe2下发 MODIFY消息到 MGW2, 将端点 5的 RemoteSDP 修改更新为 200 OK for re-INVITE消息中携带的 BS 1对应被叫侧的端点 2 的 SDP信息;
12、 MSCe2收到 MGW2返回的 REPLY消息
13、 主被叫用户仍在双向通话过程中;
14、通话结束后,被叫用户挂机, MSCe2收到 BS2发送的 Clear Request 消息;
15、 MSCe2发送 Clear Command消息到 BS2;
16、 MSCel收到 MSCe2发送的 BYE消息;
17、 MSCe 1发送 Clear Command消息到 BS 1;
18、 MSCel收到 BS1返回的 Clear Complete消息;
19、 MSCel发送 BYE的 200 OK响应消息到 MSCe2;
20、 MSCe2收到 BS2返回的 Clear Complete消息; 21、 MSCe2发送 SUBSTRACT消息到 MGW2,释放本次呼叫分配的 两个端点 5和 6;
22、 MSCe2收到 MGW2返回的 REPLY消息。
通过上述流程描述可知, 在该流程中, 在由于业务驱动或其它原因 承载的一段或者几段承载编码格式发生变化后, 也可以通过删除承载路 径中不提供 TC的方法实现承载路径的优化。
实施例 7
在有些情况下, 进行承载优化之后, 由于业务驱动, 可能还需要进 行放音、 DTMF检测上报、 插入会议资源等操作, 操作虽然不同, MSCe 处理的思路是类似的: 向相应的 MGW发送 ADD消息申请相应端点, 对 于会议, 需要按照会议参加方数目申请, 然后通过 SIP信令和 Alp接口 信令配合, 更新 BS侧的承载参数信息, 将 MGW上的端点重新纳入承载 路径中, 通过对 MGW上相应端点进行资源操作, 即可完成通话过程中 的放音, DTMF检测上报, 插入会议资源等处理。 通话结束时, MGW上 申请的各端点将被释放。 参照图 11, 以承载优化后主叫 MSCe控制向主 叫侧放带内音为例进行简要说明, 其处理流程如下:
1、 主被叫进入双向通话状态, BS 直接承载互连, 承载路径中没有 MGW存在;
2、 MSCel下发 ADD消息到 MGW1 , 请求分配两个 RTP端点, 分 别对应 BS1侧和被叫侧的承载连接端点;
3、 MSCel收到 MGW1返回的 REPLY消息,其中携带申请好的两个 RTP端点的 SDP信息, 分别主要包括 MGW1支持的编码格式,各自端点 的 IP地址, 端口号;
4、 MSCel发送 Bearer Update Request消息到 BS1 , 将 MGW1对应 BS1端点的 SDP信息转化为承载参数带给 BS1;
5、 BS1根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号, 并返回 Bearer Update Response消息;
6、 MSCel发送 re-INVITE消息到 MSCe2, 携带有 MGW1上对应被 叫侧端点 4的 SDP参数; 7、 MSCe2发送 Bearer Update Request消息到 BS2, 将 MGW1对应 被叫侧端点 4的 SDP信息转化为承载参数带给 BS2;
8、 BS2根据 Bearer Update Request消息中的承载参数更新自己保存 的对端 IP地址和端口号 , 并返回 Bearer Update Response消息;
9、 MSCe2向 MSCel返回 re-INVITE消息的 200 OK响应 ,携带 BS2 靠近主叫侧端点 7的 SDP信息;
10、 MSCel向 MSCe2发送 ACK消息;
11、 MSCel下发 MODIFY消息到 MGW1 , 将 MGW1对应被叫侧端 点 4的 RemoteSDP 改更新为被叫 BS2对应网络侧的端点 Ί的 SDP信 息;
12、 MSCel收到 MGW1返回的 REPLY消息;
13、 MSCel下发 MODIFY消息到 MGW1 , 对端点 3带内放音;
14、 MSCel收到 MGW1返回的 REPLY消息;
15、 MGW1到主叫用户单向承载建立;
16、 MSCel下发 MODIFY消息到 MGW1 , 对端点 3停止放音;
17、 MSCel收到 MGW1返回的 REPLY消息;
18、 放音结束, 主被叫重新进入双向通话状态。
由以上具体实例流程可以看出, 当主被叫通过常规呼叫流程建立起 双向用户数据承载路径或者对承载路径中某段或者某几段承载编码进行 更改后, 由移动软交换发起, 将承载路径中不提供语音编解码器的媒体 网关 (MGW )从承载路径中删除可以减少数据包时延, 改善通话质量; 在长时间双向通话过程中, 不占用 MGW端点能充分提高 MGW资源的 利用率。
实施例 8
在呼叫建立过程中, 也可以直接在主、 被叫接入网设备间建立承载。 但需建两个承载通道: 一个直接在主、 被叫接入网设备间建立承载, 另 一个是媒体网关与主叫接入网设备间的放音通道(用来进行放音:)。
由移动软交换控制主叫接入网设备进行通道的激活、 去活、 释放。 在呼叫建立过程中, 放音通道激活, 主、 被叫间承载去活; W
-21 - 呼叫接通后, 释放放音通道, 激活主、 被叫间的承载通道。
为了在呼叫接续过程中节约中间处理环节, 进而节约系统资源, 参 照图 12, 根据本发明在呼叫接续过程中进行承载路径优化, 呼叫接续过 程包括下列步骤:
Sl、 主叫侧接入设备发起呼叫。
52、 MSCe比较主被叫侧接入设备的编解码能力列表,若存在相同的 编解码, 则转入步骤 S3, 否则, 通过网絡侧的媒体网关 MGW建立主被 叫侧接入设备间的 载。
53、 直接建立语音通道。
S4、 MSCe控制所述通道的属性, 以完成振铃到接听的转换。
S5、 双向通话后, 释放 MGW的放音资源。
对于局内呼叫, MSCe比较主被叫侧接入设备的编解码能力列表, 若 存在相同的编解码能力, 主叫侧建立两个通道: 一个为主叫侧接入设备 与 MGW 间的放音承载通道, 用于放音; 一个为主叫侧接入设备与被叫 侧接入设备间的语音承载通道, 用于; ^载语音。 被叫侧只建一个主叫侧 接入设备与被叫侧接入设备间的语音承载通道, 用于承载语音。 在建立 承载过程中, 所述放音通道激活、 语音通道去活。 在被叫应答后, 删除 主叫侧的放音通道, 并激活语音承载通道。
进行局间呼叫接续时, 需进行局间协商过程。 参照图 13及图 14, 对 SIP协议进行了扩展, 现有技术只携带一个通道的承载信息, 本发明方法 携带两个通道的承载信息(即语音通道和放音通道)。 主叫侧给被叫侧的 INVITE消息中带有主叫侧 BSC的 IP端点信息和主叫侧 BSC支持的编解 码能力列表, 同时带有主叫侧 MGW的 IP端点信息和主叫侧 MGW支持 的编解码能力列表。被叫侧 MSCe比较被叫侧 BSC和主叫侧 BSC的编解 码能力列表, 若存在相同的编解码能力, 则在给被叫侧 BSC发送的承载 信息中直接携带主叫侧 BSC的 IP端点信息, 而不是携带 MGW的 IP端 点信息, 即不经过 MGW直接建立主被叫侧 BSC之间的语音通道。 再通 过 MGW建到主叫的放音通道。
本实施例中, 局间呼叫接续包括下列具体步驟: 步驟 S201、 主叫侧接入设备发起呼叫。
1、 主叫侧 BSC向主叫侧 MSCe发送 CM Service Req消息, 该消息 中携带主叫侧 BSC承载的 IP地址、 端口号和支持的 CODEC列表。
2、 主叫侧 MSCe向主叫侧 MGW发送 ADD Req消息, 要求申请 2 个 IP端点; 一个 IP端点为主叫侧 BSC的 IP端点( IP端点 3 ), 其中含有 主叫侧 BSC的 IP地址, 端口号和主叫侧 BSC与主叫侧 MGW共同支持 的 CODEC; 另一个 IP端点为局间的 IP端点 ( IP端点 4 )。
3、 主叫侧 MGW分配 IP端点后, 向主叫侧 MSCe返回分配的 IP端 点信息, 主叫侧 MSCe记录返回的 IP端点信息。
4、 主叫侧 MSCe向主叫侧 BSC发送 Assignment Request消息, 该消 息中携带主叫侧 MGW分配的 IP端点 3的 IP地址、端口号和主叫侧 BSC 与主叫侧 MGW共同支持的 CODEC。
5、 主叫侧 MSCe向被叫侧 MSCe发送 INVITE消息, 该消息中携带 两个通道信息:一个通道为主叫侧 BSC的 IP端点 2的信息及主叫侧 BSC 支持的 CODEC列表; 一个通道为主叫侧 MGW的 IP端点 4的信息及主 叫侧 MGW支持的 CODEC列表。
6、 被叫侧 MSCe向被叫侧 BSC发送寻呼消息。
7、 主叫侧 BSC建立好空口信道和 IP承载后, 主叫侧 BSC向主叫侧 MSCe发送 Assignment Complete消息, 此时主叫侧 BSC与主叫侧 MGW 间的放音通道建立完成。
8、被叫侧 BSC向被叫侧 MSCe发送寻呼响应消息,该消息中携带被 叫侧 BSC承载的 IP端点信息( IP端点 Ί )及被叫侧 BSC支持的 CODEC 列表。
此时被叫侧 MSCe已获知了主被叫侧 BSC的能力信息 , 并对主被叫 侧 BSC支持的 CODEC列表进行对比, 若存在相同的编解码, 则端到端 协商通过, 转入步骤 S203; 否则按照现有的流程, 通过 MGW建立主被 叫侧 BSC间的 7?c载。
步骤 S203、 直接建立语音通道。
9、 被叫侧 MSCe向被叫侧 MGW发送 ADD Req消息, 申请一个用 来给用户放音的 IP端点 (IP端点 5 ), 该消息中携带主叫侧 MGW的 IP 端点信息 (IP端点 4 ), 并指示给 IP端点 5放回铃音。
10、被叫侧 MGW分配 IP端点 5 ,返回给被叫侧 MSCe ,被叫侧 MSCe 记录被叫侧 MGW的 IP地址和端口号。
11、 被叫侧 MSCe向被叫侧 BSC发送 Assignmet Request消息, 该消 息中携带主叫侧 BSC的 IP端点 2的信息及主被叫侧共同支持的 CODEC。
12、 被叫侧 MSCe向主叫侧 MSCe发送 180消息, 该消息中携带两 个通道的端点信息: 一个为被叫侧 BSC的 IP端点信息( IP端点 Ί )及主 被叫侧共同支持的 CODEC, 用来建立主被叫侧 BSC间的语音通道; 一 个为被叫侧局间 IP端点 5的信息, 用来建立放音通道。
15、 主叫侧 MSCe向主叫侧 MGW发送 MODIFY消息, 4巴对端局 IP 端点 5的信息通知 IP端点 4, 由主叫侧 MGW建立局间放音承载通道。
16、 主叫侧 MGW返回响应消息。
17、 放音承载建好后, 由被叫局给主叫放回铃音。
18、 主叫侧 MSCe向主叫侧 BSC发送 BEARER UPDATE REQUEST 消息, 该消息中携带两个 IP端点信息, 第一 IP端点信息包括: IP端点 3 的信息, 该 IP端点为放音端点, 属性为激活; 第二 IP端点信息包括: IP 端点 7的信息, 该端点为语音端点 (即被叫侧 BSC的 IP端点), 及主被 叫侧共同支持的 CODEC, 属性为去活。
19、主叫侧 BSC向主叫侧 MSCe发送 BEARER UPDATE RESPONSE 消息。
20、被叫侧 BSC建立好空口信道和 IP承载后 , 向被叫侧 MSCe发送 Assignment Complete消息。
步骤 S204、 MSCe控制所述通道的属性, 以完成振铃到接听的转换。 21、被叫应答后,被叫侧 BSC给被叫侧 MSCe发送 CONNECT消息。
22、 被叫侧 MSCe给主叫侧 MSCe发送 200消息 , 该消息中携带被 叫侧 BSC的 IP端点信息 ( IP端点 Ί )。
23、 主叫侧 MSCe给主叫侧 BSC发送 BEARER UPDATE REQUEST 消息, 通知主叫侧 BSC删除放音通道, 激活语音通道。 24、 主叫侧 BSC释放放音通道, 激活语音通道, 并向主叫侧 MSCe 发送 BEARER UPDATE RESPONSE消息。
25、 主叫侧 MSCe给被叫侧 MSCe发送 ACK消息, 该消息中携带主 叫侧 BSC的 IP端点信息 ( IP端点 2 )。
步骤 S205、 双向通话后释放 MGW的放音资源。
26、 主叫侧 BSC释放放音通道, 激活语音通道, 向主叫侧 MSCe发 送 BEARER UPDATE RESPONSE 消息后, 主叫侧 MSCe 通知主叫侧 MGW释放网络侧放音通道。
28、被叫侧 MSCe收到主叫侧 ACK后通知被叫侧 MGW释放网络侧 放音通道。
实施例 9
另外, 根据本发明可提供一种端到端承载路径优化的方法, 可不通 过媒体网关直接在主、 被叫接入网设备间建立承载, 由被叫终端直接给 主叫侧放音。 参照图 15 , 具体包括:
1、 主叫 BSC向 MSCe发送 CM Service Req消息, 带 BSC侧承载的
IP地址、 端口号, 支持的 Codec列表;
2、 MSCe向被叫侧 BSC发送寻呼请求消息;
3、 被叫 BSC给向 MSCe寻呼响应消息, 带 BSC侧承载的 IP地址、 端口号, 支持的 Codec列表; 并且带标志支持被叫终端支持向主叫放回 铃音;
4、 MSCe判断主、被叫 BSC的 Codec列表,如果有共同支持的 Codec, 则不再向 MGW请求承载的 IP端点; MSCe给主叫侧 BSC发送指配请求 消息, 带被叫侧 BSC的 IP地址、 端口号, 共同支持的 Codec;
5、 MSCe给被叫 BSC发送指配请求, 带主叫侧 BSC的 IP地址、 端 口号, 共同支持的 Codec; 由主、 被叫 BSC直接交互建立 DP承载。 同时 在指配请求消息中带参数要求被叫终端直接给主叫终端放回铃音。
6、 7、 主、 被叫发送指配完成消息给 MSCe。
8、在空口信道和 BSC间承载建好后, 由被叫终端直接给主叫放回铃 9、 被叫应答, 被叫终端停止放回铃音, 主、 被叫进行正常通话。 主、 被叫 BSC直接交互, 减少了不必要的中间处理环节, 特别是当 主、 被叫在同一个 BSC时, 可以很好地提高语音质量。
被叫接通时, 不用再修改承载, 避免了被叫接通时的短暂时间内听 不到音的情况。 被叫直接给主叫放音, 可以实现用户自己在终端上设置 针对不同主叫用户的特性化回铃音。
实施例 10
根据本发明在移动通信系统中实现用户的局间切换时的承载路径更 新方案。
在通话态, 用户发生切换, 需要从新的接入网设备建承载。
首先, 由源侧 BS向源侧 MSCe发出切换申请, 由源侧 MSCe要求源 侧 MGW分配第一 IP端点如 IP端点 7, 以与目标局建立承载, 并将该第 一 IP 端点的信息和源局提供的编解码 (CODEC ) 列表发送至目标侧 MSCe。 参照图 16, 具体如下:
步骤 1 , 源侧 BS 向源侧 MSCe发送需要切换申请 ( HANDOFF
REQUIRED ) 消息, 该消息包括硬切换候选小区列表;
步骤 2, 源侧 MSCe通过发送加入 ( ADD )命令在源侧 MGW建立 承载信息, 要求源侧 MGW分配第一 IP端点 7, 用于与目标局联系; 步骤 3 , 源侧 MGW发送回复(Reply ) 消息确认加入结果, 该回复 消息包括所分配的第一 IP端点 7的 IP地址和端口号; ' 步骤 4, 源侧 MSCe发送 FACDIR2 ( FacilitiesDirective2 INVOKE 设备指示 ) 消息至目标局 MSCe;
步骤 5 , 源侧 MSCe发送初始呼叫 ( INVITE ) 消息至目标局 MSCe, 该初始呼叫消息携带源侧 MGW第一 IP端点 7的信息(包括 IP地址和端 口号)和源局提供的 CODEC列表。
接着, 在步驟 6-12, 直接在源侧 MGW和目标侧 BS之间建立 IP承 载, 此过程中 , 目标侧 BS从源局提供的 CODEC列表中选择 CODEC。 其中: 步驟 6, 目标侧 MSCe在接收到源侧 MSCe发送的 FACDIR2消息和 初始呼叫消息后, 发送切换请求( HANDOFF REQUEST ) 消息至目标侧 BS, 该切换请求消息携带源侧 MGW第一 IP端点 7的信息;
步骤 7, 目标侧 BS将其 IP端点 10的信息和其 CODEC列表通过切 换请求应答消息发送至目标侧 MSCe; 目标侧 MSCe接收到该切换请求应 答消息后, 将其中的目标侧 BS的 CODEC列表与源局提供的 CODEC列 表比较, 如果二者存在相同的 CODEC, 则选择一个相同的 CODEC, 步骤 8, 目标侧 MSCe发送 facdir2 ( FacilitiesDirective2 RETURN RESULT设备指示响应) 消息至源侧 MSCe;
步骤 9,目标侧 MSCe将目标侧 BS的 IP端点 10的信息和目标侧 BS 选择的 CODEC经 200 OK消息直接发送至源侧 MSCe;
步骤 10, 源侧 MSCe将目标侧 BS的 IP端点 10的信息通过修改 ( MODIFY ) 消息发送至源侧 MGW, 更新该 MGW的承载信息;
步骤 11 , 源侧 MGW建立其第一 IP端点 7与目标侧 BS的 IP端点 10之间的 IP承载, 并利用回复( Reply ) 消息通知源侧 MSCe;
步骤 12, 源侧 MSCe向目标侧 MSCe发送应答(ACK ) 消息, 以通 知目标侧 MSCe源侧 MGW第一 IP端点 7与目标侧 BS的 IP端点 10之 间的 IP承载建立。
当源局和目标局之间的 IP承载建立后, 在步骤 13-20, 完成移动台 从源侧 BS至目标侧 BS的切换调整。 其中:
步骤 13 , 源侧 MSCe发送切换命令 ( HANDOFF COMMAND )消息 至源侧 BS并通过该 BS令 MS进行切换;
步骤 14,当 MS已经开始切换时,源侧 BS发送切换开始( HANDOFF COMMENCED ) 消息至源侧 MSCe;
步骤 15, 当 MS 切换到目标局后, 目标侧 BS 发送切换完成
( HANDOFF COMPLETE ) 消息至目标侧 MSCe;
步骤 16,目标侧 MSCe向源侧 MSCe发送移动台进入信道( Mobile On Channel, MSONCH ) 消息, 以表明目标局的切换已完成; 步驟 17, 当源侧 MSCe收到 MSONCH移动台进入信道消息时, 切 换成功, 源侧 MSCe发送減去 (SUBTRACT )命令至源侧 MGW, 令其 拆除到源侧 MGW的 IP端点 5的承载路径;
切换前承载通路为:接入侧 IP端点 6到 MGW上的 IP端点 5 , MGW 上的 IP端点 5到 IP端点 4, IP端点 4与呼叫的另一方交互。
切换完成后, IP端点 4与 IP端点 7接, IP端点 7到新的接入侧 IP 端点 10。 接入设备 IP端点 6和 MGW上的 IP端点 5已经不需要, 应该 删除。
步骤 18, —旦切换完成(步骤 16 ), 源侧 MSCe 即发送清除命令
( CLEAR COMMAND )至源侧 BS;
步骤 19, 源侧 MGW发送回复消息至源侧 MSCe, 确认已拆除 IP端 点 5的承载路径;
步骤 20, 源侧 BS发送清除完成 ( CLEAR COMPLETE )消息至源侧 MSCe以响应清除命令。
如图 17所示, 在本发明的实施例中, 通常在局端设备中, 设置有一 种承载路径管理装置 01 , 具体包括:
承载建立模块 02, 用于获取主叫侧接入设备和被叫侧接入设备信息 并控制呼叫侧接入设备、 被叫侧接入设备以及媒体网关之间建立承载; 判断模块 03, 用于比较判断主叫侧接入设备与被叫侧接入设备的编 解码能力是否相同和 /或判断媒体网关两侧承载连接端点的数据编码格式 是否相同, 并将判断结果信息发送给承载更新模块;
承载更新模块 04, 根据判断模块的判断结果信息控制呼叫侧接入设 备与被叫侧接入设备之间承载路径调整。
该装置还包括:
资源管理模块 05, 根据所述承载路径调整信息控制相应媒体网关释 放与源接入设备及被叫侧接入设备之间建立的承载资源。
当所述判断模块判断承载路径中的媒体网关两侧承载连接端点的数 据编码格式相同,则承载更新模块将该媒体网关从所述承载路径中删除, 并更新与该媒体网关相邻的承载连接端点的相关参数。
当所述判断模块判断呼叫侧接入设备与被叫侧接入设备的编码能力 相同, 承载更新模块分别向呼叫侧接入设备发送被叫侧接入设备的端点 信息, 以及向被叫侧接入设备发送源接入设备的端点信息, 并控制主叫 侧接入设备与被叫侧接入设备之间直接建立承载。
本发明当移动台在源侧局和目标局之间进行切换时, 通过目标侧移 动交换中心仿真交换源侧媒体网关和目标侧基站的承载信息, 直接在源 侧媒体网关和目标侧基站之间建立 IP承载, 无须在源侧媒体网关和目标 侧媒体网关之间以及目标侧媒体网关之间分别建立 IP承载, 使得源侧媒 体网关无须通过目标侧媒体网关即可以直接与目标侧基站进行媒体交 互, 从而优化了承载处理, 减少中间处理环节, 提高媒体流信息传输质 量, 节约了目标侧媒体网关承载资源。
上述实施例用于说明和解释本发明的原理。 可以理解, 本发明的具 体实施方式不限于此。 对于本领域技术人员而言, 在不脱离本发明的实 质和范围的前提下进行的各种变更和修改均涵盖在本发明的保护范围之 内。

Claims (1)

  1. 权 利 要 求
    1、 一种承载路径优化方法, 其特征在于, 包括:
    主叫用户呼叫被叫用户, 建立本次呼叫的承载路径后, 判断承载路 径中对应媒体网关两侧承载连接端点的数据编码格式是否相同,
    若所述媒体网关两侧承载连接端点的数据编码格式相同, 则将该媒 体网关从所述承载路径中删除, 并更新与该媒体网关相邻的承载连接端 点的承载参数。
    2、 如权利要求 1所述的方法, 其特征在于, 所述呼叫为同一个交换 局内的呼叫, 判断出对应媒体网关两侧承载连接端点的数据编码格式相 同, 则将该媒体网关从所述承载路径中删除, 更新主叫侧或 /和被叫侧接 入网设备对应网络侧的承载连接端点的承载参数, 使主叫侧与被叫侧接 入网设备之间承载直接互连。
    3、 如权利要求 1所述的方法, 其特征在于, 所述呼叫为交换局间呼 叫, 当主叫侧或 /和被叫侧媒体网关两侧承载连接端点的数据编码格式相 同, 则将相应的主叫侧或 /和被叫侧媒体网关从承载路径中删除, 并更新 相关网络侧的承载连接端点的承载参数。
    4、 如权利要求 3所述的方法, 其特征在于, 当被叫侧媒体网关两侧 承载连接端点的数据编码格式相同, 主叫侧媒体网关两侧承载连接端点 的数据编码格式不同, 则将被叫侧媒体网关从承载路径中删除, 更新被 叫对应网络侧的承载连接端点和主叫媒体网关对应被叫侧的承载连接端 点的承载参数, 使被叫侧接入网设备与主叫侧媒体网关之间承载直接互 连。
    5、 如权利要求 4所述的方法, 其特征在于, 所述删除被叫侧媒体网 关及更新承载参数, 具体包括如下步驟:
    被叫侧移动软交换向主叫侧移动软交换发送更新请求消息, 携带被 叫侧基站 BS对应网络侧端点的会话描述协议 SDP信息;
    主叫侧移动软交换向被叫侧移动软交换返回应答消息, '携带主叫侧 媒体网关对应被叫侧端点的 SDP信息;
    被叫侧移动软交换发送媒体更新请求消息到被叫侧基站 BS , 携带主 叫侧媒体网关对应被叫侧端点的 SDP信息转化后的承载参数; 被叫侧基站 BS 用所述媒体更新请求消息中携带的所述承载参数更 新保存的对端地址信息;
    主叫侧软交换下发修改消息到主叫侧媒体网关, 将其对应被叫侧端 点的远程 SDP更新为被叫侧基站 BS对应网络侧端点的 SDP信息; 被叫侧移动软交换发送删除消息给被叫侧媒体网关, 锋放被叫侧媒 体网关为本次呼叫分配的两个端点, 将被叫侧媒体网关从承载路径中删 除;被叫侧基站 BS对应网络侧端点与主叫侧媒体网关对应被叫侧端点直 接互连。
    6、 如权利要求 3所述的方法, 其特征在于, 当被叫侧媒体网关两侧 承载连接端点的数据编码格式不同, 主叫侧媒体网关两侧承载连接端点 的数据编码格式相同, 则将主叫侧媒体网关从承载路径中删除, 更新主 叫对应网络侧的承载连接端点和被叫侧媒体网关对应主叫侧的承载连接 端点的承载参数, 使主叫侧接入网设备与被叫侧媒体网关之间承载直接 互连。
    7、 如权利要求 6所述的方法, 其特征在于, 所述删除主叫侧媒体网 关及更新承载参数, 具体包括如下步驟:
    主叫侧移动软交换向被叫侧移动软交换发送重新请求消息, 携带主 叫侧 BS对应网络侧端点的 SDP信息;
    被叫侧移动软交换判断返回应答消息, 携带被叫侧媒体网关对应主 叫侧端点的 SDP信息;
    被叫侧移动软交换下发修改消息到被叫侧媒体网关, 将该 MGW上 对应主叫侧端点的远程 SDP 更新为主叫侧基站 BS 对应网络侧端点的 SDP信息;
    主叫侧移动软交换发送媒体更新请求消息到主叫侧基站 BS , 携带被 叫侧媒体网关对应主叫侧端点的 SDP信息转化后的承载参数;
    主叫侧基站 BS 用主叫侧移动软交换发送的媒体更新请求消息中携 带的所述承载参数更新保存的对端地址信息;
    主叫侧移动软交换发送删除消息给主叫侧媒体网关, 释放主叫侧媒 体网关上为本次呼叫分配的两个端点, 将主叫侧媒体网关从承载路径中 删除;主叫侧基站 BS对应网络侧端点与被叫侧媒体网关对应主叫侧端点 直接互连。
    8、 如权利要求 3所述的方法, 其特征在于, 若被叫侧和主叫侧对应 媒体网关两侧承载连接端点的数据编码格式相同, 则将被叫侧媒体网关 和主叫侧媒体网关分别从承载路径中删除, 更新主叫和被叫对应网络侧 的承载连接端点的承载参数, 使使主叫和被叫接入网设备之间承载直接 互连。
    9、 如权利要求 8所述的方法, 其特征在于, 所述删除被叫侧媒体网 关及更新承载参数具体包括如下步骤:
    被叫侧移动软交换向主叫侧移动软交换发送更新请求消息, 携带被 叫侧 BS对应网络侧端点的会话描述协议 SDP信息;
    主叫侧软交换向被叫侧软交换返回响应消息,携带主叫侧 BS对应网 络侧端点的 SDP信息;
    主叫侧移动软交换发送媒体更新请求消息到主叫侧 BS, 携带被叫侧
    BS对应网络侧端点的 SDP信息转化后的承载参数;
    主叫侧基站 BS 用主叫侧移动软交换发送的媒体更新请求消息中携 带的所述承载参数更新保存的对端地址信息;
    被叫侧移动软交换发送媒体更新请求消息到被叫侧 BS, 携带主叫侧 BS对应网络侧端点的 SDP信息转化后的承载参数;
    被叫侧基站 BS 用被叫侧移动软交换发送的媒体更新请求消息中携 带的所述承载参数更新保存的对端地址信息;
    主叫侧移动软交换发送删除消息给主叫侧媒体网关, 释放主叫侧媒 体网关上为本次呼叫分配的两个端点, 将主叫侧媒体网关从承载路径中 删除;
    被叫侧移动软交换发送删除消息给被叫侧媒体网关, 释放被叫侧媒 体网关上为本次呼叫分配的两个端点 , 将被叫侧媒体网关从承载路径中 删除; 主叫侧基站 BS对应网络侧的端点与被叫侧基站 BS对应网络侧的 端点直接互连。 10、 如权利要求 1 所述的方法, 其特征在于, 所述呼叫为经过汇接 局的交换局间呼叫, 局间承载路径建立后, 判断所述承载路径上的中间 媒体网关两侧承载连接端点的数据编码格式是否相同, 若相同, 则将该 中间媒体网关从承载路径中删除;
    向所述中间媒体网关对应的移动软交换发送更新请求消息。
    11、 如权利要求 10所述的方法, 其特征在于, 所述更新请求消息由 上一级媒体网关对应的移动软交换传送到下一级媒体网关对应的移动软 交换;
    各级移动软交换分别判断其对应的媒体网关两侧端点的数据编码格 式是否相同, 若相同, 则在承载路径中删除对应的媒体网关。
    12、 如权利要求 1所述的方法, 其特征在于, 还包括:
    在承载路径建立前, 比较主、 被叫侧接入设备的编解码能力, 若存 在相同的编解码能力, 则在主叫侧接入设备与被叫侧接入设备间直接建 立承载连接, 并建立主叫侧接入设备和媒体网关间的放音通道; 否则, 通过网络侧的媒体网关建立主、 被叫侧接入设备间的承载连接;
    所述承载连接包括: 主叫侧接入设备与被叫侧接入设备间直接建立 语音通道, 以及主叫侧接入设备与媒体网关间建立的放音通道。
    13、 如权利要求 12所述的方法, 其特征在于,
    在呼叫建立过程中, 所述主叫侧接入设备与媒体网关间的放音通道 激活, 所述主、 被叫接入设备的承载通道去活;
    呼叫建立后, 舞放所述放音通道, 激活主、 被叫间的承载通道。
    14、 如权利要求 12所述的方法, 其特征在于, 所述直接建立主被叫 侧接入设备间的承载连接, 包括:
    在发给主叫侧接入设备的承载信息中携带被叫侧接入设备的 IP端点 信息和主被叫侧接入设备共同支持的编解码, 在发给被叫侧接入设备的 承载信息中携带主叫侧接入设备的 IP端点信息和主被叫侧接入设备共同 支持的编解码, 以建立语音通道; 以及
    在发给主叫侧接入设备的承载信息中携带相应媒体网关的 IP端点信 息, 以建立放音通道。 15、 如权利要求 14所述的方法, 其特征在于,
    所述发给主叫侧接入设备的承载信息中携带主叫侧接入设备和媒体 网关之间的放音通道属性信息 , 以及主叫侧接入设备与被叫侧接入设备 之间的语音通道属性信息。
    16、 一种承载路径管理装置, 其特征在于, 包括:
    承载建立模块, 用于获取主叫侧接入设备和被叫侧接入设备信息并 控制呼叫侧接入设备、 被叫侧接入设备以及媒体网关之间建立承载; 判断模块, 用于比较判断主叫侧接入设备与被叫侧接入设备的编解 码能力是否相同和 /或判断媒体网关两侧承载连接端点的数据编码格式是 否相同, 并将判断结果信息发送给承载更新模块;
    承载更新模块 , 根据判断模块的判断结果信息控制呼叫侧接入设备 与被叫侧接入设备之间承载路径调整。
    17、 如权利要求 16所述的装置, 其特征在于, 还包括:
    资源管理模块, 根据所述承载路径调整信息控制相应媒体网关释放 与源接入设备及被叫侧接入设备之间建立的承载资源。
    18、 如权利要求 16所述的装置, 其特征在于,
    当所述判断模块判断承载路径中的媒体网关两侧承载连接端点的数 据编码格式相同,则承载更新模块将该媒体网关从所述承载路径中删除, 并更新与该媒体网关相邻的承载连接端点的相关参数。
    19、 如权利要求 16所述的装置, 其特征在于,
    当所述判断模块判断呼叫侧接入设备与被叫侧接入设备的编码能力 相同, 承载更新模块分别向呼叫侧接入设备发送被叫侧接入设备的端点 信息, 以及向被叫侧接入设备发送源接入设备的端点信息, 并控制主叫 侧接入设备与被叫侧接入设备之间直接建立承载。
    20、 一种呼叫接续的方法, 其特征在于, 包括下列步骤:
    对主被叫侧接入设备的编解码能力列表进行对比, 若存在相同的编 解码, 则直接建立主被叫侧接入设备间的承载;
    否则, 通过网络侧的媒体网关 MGW建立主被叫侧接入设备间的承 21、 如权利要求 20所述的方法, 其特征在于, 所述直接建立主被叫 侧接入设备间的承载包括: 建立主被叫侧接入设备间的语音通道, 以及 建立 MGW与接入设备间放音通道。
    22、 如权利要求 20所述的方法, 其特征在于, 所述主被叫侧接入设 备在同一 MSCe覆盖范围内, 由 MSCe比较主被叫侧接入设备的编解码 能力列表。
    23、 如权利要求 22所述的方法, 其特征在于, 存在相同的编解码能 力时, 所述 MSCe在发给主叫侧接入设备的承载信息中携带被叫侧接入 设备的 IP端点信息和主被叫侧接入设备共同支持的编解码能力, 以建立 语音通道, 并携带 MGW的 IP端点信息, 以建立放音通道。
    24、 如权利要求 22所述的方法, 其特征在于, 存在相同的编解码能 力时, 所述 MSCe在发给被叫侧接入设备的承载信息中携带主叫侧接入 设备的 IP端点信息和主被叫侧接入设备共同支持的编解码能力, 以建立 语音通道。
    25、 如权利要求 23所述的方法, 其特征在于, 进一步包括: 在接续过程中, MSCe发给主叫侧接入设备的承载信息中包括: 主叫 侧接入设备与 MGW之间的放音通道属性为激活, 以及主叫侧接入设备 与被叫侧接入设备之间的语音通道属性为去活。
    26、 如权利要求 24所述的方法, 其特征在于, 进一步包括: 当在被叫应答后, 将主叫侧接入设备与 MGW之间的放音通道删除,
    MSCe释放相应 MGW上的 IP端点资源。
    27、 如权利要 22所述的方法, 其特征在于, 所述主被叫侧接入设备 在不同的 MSCe覆盖范围内, 则由被叫侧 MSCe比较主被叫侧接入设备 的编解码能力列表。
    28、 如权利要 27所述的方法, 其特征在于, 所述被叫侧 MSCe比较 主被叫侧接入设备的编解码能力列表包括下列步骤:
    主叫侧 MSCe向被叫侧 MSCe发送的承载信息中携带主叫侧接入设 备的 IP端点信息和主叫侧接入设备支持的编解码能力列表, 以及主叫侧 MGW的 IP端点信息和主叫侧 MGW支持编解码能力列表; 被叫侧 MSCe从被叫侧获取被叫侧接入设备的 IP端点信息和被叫侧 接入设备支持的编解码能力列表, 以及被叫侧 MGW的 IP端点信息和被 叫侧 MGW支持编解码能力列表;
    被叫侧 MSCe完成主被叫侧接入设备的编解码能力列表的比较。 29、 如权利要 27所述的方法, 其特征在于, 存在相同的编解码能力 时, 被叫侧 MSCe在发给被叫侧接入设备的承载信息中携带主叫侧接入 设备的 IP端点信息和主被叫侧接入设备共同支持的编解码能力, 以建立 语音通道。
    30、 如权利要求 27所述的方法, 其特征在于, 存在相同的编解码能 力时, 被叫侧 MSCe在发给主叫侧 MSCe的承载信息中携带被叫侧接入 设备的 IP端点信息和主被叫侧接入设备共同支持的编解码能力, 以建立 语音通道; 以及携带被叫侧 MGW的 IP端点信息和主被叫侧 MGW共同 支持编解码能力列表, 以建立放音通道。
    31、 如权利要求 30所述的方法, 其特征在于, 主叫侧 MSCe将被叫 侧 MSCe发来的被叫侧接入设备的 IP端点信息及主被叫接入设备共同支 持的编解码能力发给主叫侧接入设备。
    32、 如权利要求 29、 30或 31所述的方法, 其特征在于, 在接续过 程中, 主叫侧 MSCe发给主叫侧接入设备的承载信息中包括: 主叫侧接 入设备与 MGW之间的放音通道属性为激活, 以及主叫侧接入设备与被 叫侧接入设备之间的语音通道属性为去活。
    33、 如权利要求 29、 30或 31所述的方法, 其特征在于, 在被叫应答 后, 主叫侧 MSCe发给主叫侧接入设备的承载信息包括: 删除主叫侧接 入设备与 MGW之间的放音通道, 以及主叫侧接入设备与被叫侧接入设 备之间的语音通道属性为激活。
    34、 如权利要求 33所述的方法, 其特征在于, 所述删除主叫侧接入 设备与 MGW之间的放音通道后, 包括下列步骤:
    主叫侧 MSCe释放主叫侧 MGW上的 IP端点资源;
    主叫侧 MSCe通知被叫侧 MSCe释放放音通道;
    被叫侧 MSCe释放被叫侧 MGW上的 IP端点资源。 35、 一种实现局间切换的方法, 其特征在于, 包括: 当移动台从源局切换至目标局时, 源侧移动交换中心根据源侧基站 的切换请求, 要求源侧媒体网关分配第一 IP端点, 并将该第一 IP端点的 信息和源局提供的编解码列表发送至目标侧移动交换中心;
    目标侧移动交换中心在目标侧基站的 IP端点与所述第一 IP端点之 间直接建立 IP承载。
    36、 如权利要求 35所述的方法, 其特征在于, 进一步包括: 所述在目标侧基站的 IP端点与所述第一 IP端点之间直接建立 IP承 载, 具体包括:
    所述目标侧基站接收所述目标侧移动交换中心发送的第一 IP端点的 信息和源局提供的编解码列表;
    所述目标侧基站从所述编解码列表中选择编解码, 并将其 IP端点的 信息和其所选择的编解码发送至所述目标侧移动交换中心;
    所述目标侧移动交换中心将接收到的所述目标侧基站 IP端点的信息 和该目标侧基站所选择的编解码发送至所述源侧移动交换中心;
    所述源侧移动交换中心将所述目标侧基站 IP端点的信息发送至所述 源侧媒体网关;
    所述源侧媒体网关在所述第一 IP端点与所述目标侧基站 IP端点之 间建立承载。
    37、 如权利要求 36所述的方法, 其特征在于,
    所述第一 IP端点的信息携带在切换请求消息中;
    所述目标侧基站 IP端点的信息和编解码列表携带在切换请求应答消 息中。
    38、 如权利要求 36所述的方法, 其特征在于,
    所述目标侧基站 IP端点的信息和所述目标侧移动交换中心所选择的 编解码携带在 200 OK消息中。
    39、 如权利要求 36所述的方法, 其特征在于,
    所述目标侧基站 IP端点的信息携带在修改消息中。 40、 如权利要求 36所述的方法, 其特征在于,
    所述第一 IP端点的信息至少包括该第一 IP端点的 IP地址和端口号; 所述目标侧基站 IP端点的信息至少包括该目标侧基站 IP端点的 IP地址 和端口号。
CN200680006576.2A 2005-10-14 2006-10-12 承载路径建立、优化方法及装置 Expired - Fee Related CN101288320B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200680006576.2A CN101288320B (zh) 2005-10-14 2006-10-12 承载路径建立、优化方法及装置

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
CNA2005101129260A CN1870772A (zh) 2005-10-14 2005-10-14 一种承载路径优化方法
CN200510112926.0 2005-10-14
CN200510124058.8 2005-11-28
CNA2005101240588A CN1870824A (zh) 2005-11-28 2005-11-28 一种呼叫接续的方法
CN200510121523.2 2005-12-31
CNA2005101215232A CN1874544A (zh) 2005-12-31 2005-12-31 一种承载更新系统及方法
CN200610033176.2 2006-01-18
CNA2006100331762A CN1874601A (zh) 2006-01-18 2006-01-18 Cdma系统中实现局间切换的方法
PCT/CN2006/002688 WO2007041963A1 (fr) 2005-10-14 2006-10-12 Procédé permettant d’établir, d’optimiser un chemin support et appareil idoine
CN200680006576.2A CN101288320B (zh) 2005-10-14 2006-10-12 承载路径建立、优化方法及装置

Publications (2)

Publication Number Publication Date
CN101288320A true CN101288320A (zh) 2008-10-15
CN101288320B CN101288320B (zh) 2013-01-09

Family

ID=37444308

Family Applications (2)

Application Number Title Priority Date Filing Date
CNA2005101129260A Pending CN1870772A (zh) 2005-10-14 2005-10-14 一种承载路径优化方法
CN200680006576.2A Expired - Fee Related CN101288320B (zh) 2005-10-14 2006-10-12 承载路径建立、优化方法及装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CNA2005101129260A Pending CN1870772A (zh) 2005-10-14 2005-10-14 一种承载路径优化方法

Country Status (1)

Country Link
CN (2) CN1870772A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103004260A (zh) * 2010-07-23 2013-03-27 瑞典爱立信有限公司 电信网络中的选通控制

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100456893C (zh) * 2006-09-30 2009-01-28 华为技术有限公司 一种语音数据的承载方法及系统
CN101237603B (zh) * 2007-02-02 2012-07-04 华为技术有限公司 一种实现gsm无线网和核心网间接口ip化的方法及系统
CN101316379B (zh) * 2007-06-01 2013-06-05 华为技术有限公司 第二代移动通信系统中实现a接口ip化的方法、设备及系统
RU2431239C2 (ru) * 2007-02-02 2011-10-10 Хуавэй Текнолоджиз Ко., Лтд. Способ, устройство и система для установления канала-носителя в gsm-сети
CN101459907B (zh) * 2008-03-26 2010-09-29 中兴通讯股份有限公司 一种指示服务网关承载管理的方法
CN101686522B (zh) * 2008-09-22 2012-04-04 华为技术有限公司 路由优化承载的处理方法、装置
ES2581326T3 (es) 2011-07-18 2016-09-05 Huawei Technologies Co., Ltd. Método y dispositivo para transmitir datos de flujo multimedia en un sistema informático en nube
CN104244294B (zh) * 2013-06-07 2018-03-16 电信科学技术研究院 一种直接通信路径倒换方法和设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2217838C (en) * 1996-11-07 2003-07-29 At&T Corp. Wan-based voice gateway
ATE392096T1 (de) * 2001-11-27 2008-04-15 Nokia Siemens Networks Gmbh Verfahren zum austauschen von nach unterschiedlichen codierungsgesetzen erzeugten nutzinformationen zwischen wenigstens 2 teilnehmerendeinrichtungen
EP1341356A3 (en) * 2002-02-25 2008-10-22 Alcatel Lucent Two-way video gateway and method for establishing an audio and video communications link between dissimilar multimedia terminals
CN100397846C (zh) * 2003-08-19 2008-06-25 华为技术有限公司 媒体网关控制器支持不同的端点标识的方法
CN100544514C (zh) * 2003-11-14 2009-09-23 中兴通讯股份有限公司 移动软交换网络的切换实现方法和装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103004260A (zh) * 2010-07-23 2013-03-27 瑞典爱立信有限公司 电信网络中的选通控制
US9374763B2 (en) 2010-07-23 2016-06-21 Telefonaktiebolaget Lm Ericsson (Publ) Gating control in a telecommunication system
CN103004260B (zh) * 2010-07-23 2016-11-16 瑞典爱立信有限公司 电信网络中的选通控制

Also Published As

Publication number Publication date
CN1870772A (zh) 2006-11-29
CN101288320B (zh) 2013-01-09

Similar Documents

Publication Publication Date Title
JP4567359B2 (ja) ネットワーク・リソースの最適化による、エンド・ユーザの要求に応じた会議運営のための迅速なネットワークsip/sdp手順
CN101288320A (zh) 承载路径建立、优化方法及装置
CN100417288C (zh) 将多媒体呼叫回退为语音呼叫的方法
EP2114049B1 (en) Video interworking gateway, system and method for realizing video call service
EP1487221B1 (en) Server component redirection of new media path portion between packet-switched and circuit-switched portions of mobile switching center
JP4532048B2 (ja) セルラ・ネットワークにおいて、呼制御とベアラ制御とを分離して、レイヤ・アドレスと論理ポイントとを逆方向に転送する、基本的呼の設定の実施方法
EP1736015B1 (en) System and method for providing early ringback by a home legacy mobile station domain network
JP2006520164A (ja) 広域通信網電話システムへの局所領域電話システムの拡張
CN101141807B (zh) 一种编解码协商方法
KR100559011B1 (ko) 가입자 기반 링백톤 서비스의 듀얼 코덱을 이용한 음질개선 방법
CN101128023B (zh) 一种建立切换承载的方法
KR100641326B1 (ko) 차세대 이동통신망에서의 호처리 방법
CN101668229A (zh) 多媒体铃音业务的呼叫和控制方法、装置及系统
CN100477695C (zh) VoIP语音通信系统的回铃音和提示音实现方法及装置
CN103428781B (zh) 一种ip语音通话切换的方法及系统、用户设备
CN102369709A (zh) 一种实现无线ip多媒体通信的方法及系统
WO2007041963A1 (fr) Procédé permettant d’établir, d’optimiser un chemin support et appareil idoine
CN100450223C (zh) 一种在移动软交换架构下实现集群业务的方法
CN101394445B (zh) 一种实现编解码转换功能的系统和方法
CN101282574A (zh) 通信系统、设备以及多媒体呼叫方法
CN101166302B (zh) 业务切换方法和系统
CN101931907A (zh) 一种分组核心网呼叫传统电路域网络用户的方法及系统
CN101646271B (zh) 实现应答前多媒体服务的方法、设备及系统
CN100356803C (zh) 控制业务承载方式改变的方法
KR100566299B1 (ko) 가입자 기반 링백톤 서비스의 듀얼 음원 제공 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20130109