3GPP定义的IMSnbsp;ECT业务与Conf…
Multimedia Telephony Service and supplementary services;
Stage 1
它定义了IMS业务的基本需求,重点在于列举了IMS所应支持的各补充业务功能列表、功能简单描述、各业务间冲突关系。
其中提到了Explicit Communication Transfer (ECT),Three-Party (3PTY),CONFerence (CONF)。
通过Annex E (informative):Bibliography references可知,各业务的功能主要继承了ETSI的ISDN业务标准。
各业务都有单独标准来定义其功能需求、签约激活模式、业务流程、各角色的功能细节及业务冲突关系。
Three-Party前几年曾经看到过单独的标准,但最近几年合并到CONFerence (CONF)业务中。
3GPP TS 24.628
Core Network (CN) subsystem;
Protocol specification
包括了各种放音模式的流程。放音模式在传统网络中的重要功能,各运营商往往对这部分功能有不同的要求。
=========================================
Explicit Communication Transfer (ECT)
其主要标准是:3GPP TS 24.629
Explicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystem;
Protocol specification
ECT业务分为Blind transfer(转接-盲转),Consultative transfer(转接-询问转)。
ECT分为 端到端流程 与3PCC流程。
ECT标准中定义了四个流程
1,端到端流程-盲转
A与B通话后,B发对话内refer给A(request To: UE-A,Referred-To: UE-C, Referred-By: UE-B),让A与C通话
要求:AS-B收到refer后, 1)判断refer是用于ECT。
2)把refer-to变成private-url,并保存原值(PUI C) 3)Referred-By 头与privacy头要保证正确性。
AS-B收到A发来的invite及后续ACK时,1)判断req-uri是自己原来产生的private-url
2)把req-uri(to\route也可能改) 由private-url变为原值(PUI C). 3)Referred-By 头与privacy头要保证正确性。
AS-A收到refer后:存储refer-to头与Referred-By头。而当收到A发的invite(用原存的refer-to头来关联)时,更新Referred-By头或当Referred-By头错误时拒绝invite。
异常流程:24.629的4.5.2.4.1.2.2A, 4.5.2.4.1.2.3最后两段, 24.628的 4.7.2.9.7
当refer发出后,对端回403或503 或特定notify(消息体中指示420),AS-B给业务用户回notify+202,此后按3PCC流程,发invite(盲转)或reinvite(询问转)给 对端。即端到端流程失败时,AS自动转换为3PCC流程与reinvite流程。
A与B在原对话中交换allow时,AS就知道哪个UE是否支持refer(或运营商不愿意把refer发给对端,控制不执行 端到端流程)。则AS不用发refer给对端就可以自行开启3PCC流程。
2,端到端流程-询问转
A与B通话,B也与C在通话中。B发对话内refer给A(字段同上,但含replace字段),让A与C通话。
AS-B收到refer,
行为同盲转,另外 删除并保存replace字段
AS-B收到A发来的invite及后续ACK时,
行为同盲转,另外 补充replace字段。
要求:AS-C及 AS-B与UE_C之间的各B2BUA网元均要替换replace头。
3,3PCC流程-盲转
A与B通话后,B发refer给A,让A与C通话。
标准要求参考3GPP TS 24.628 Figure E.1与E.5。但其中的流程似乎是三方通话的且不完整,二者的区别似乎是invite中是否带null SDP。
如果参考 3PCC流程-询问转 的流程,很容易理解 3PCC流程-盲转 的流程
4,3PCC流程-询问转
A与B通话,B也与C在通话中。B发refer给A,让A与C通话。
在3PCC流程中,终端的要求较低,只要能发出refer信令来触发ECT业务即可(传统SIP终端只要增强refer信令支持即可,并且refer协议不用全部支持)。其它业务流程由AS控制。而端到端业务流程中,除了终端发refer来触发ECT业务外,其它业务流程中对终端、AS的要求都较高(比如终端收到refer发invite,根据ECT业务进程发notify等)。
由于终端厂家、终端类型较多,终端的改造升级涉及面较广,工程、商务实施更困难。 实际组网时,运营商可能更倾向于3PCC过程,此外,端到端流程实现的难点较大,标准中也有若干要求实现较难或者说有可改进的空间,具体如下面各个细节。
3GPP 端到端流程在细节上与RFC中的transfer流程区别已较大,因为3GPP标准对于计费、各厂商互通性、运营商管控 方面考虑较多。
端到端流程 细节点1:AS-A虽然是非业务用户的AS,但也需要识别ECT业务。
从附录的两个端到端流程中可以看出,以盲转流程中的AS-A,AS-B为例:
1) 不仅 ECT业务用户的AS(AS-B)需要识别出ECT业务特征来对信令头进行修改、缓存信令头并在收到后续invite时匹配原对话。
2) 而且非业务用户的AS(AS-A)也需要识别ECT业务,并缓存refer-to头与refer-by头。 目的可能是为了满足计费模型:它要求AS-A对于 UE-A发出的新invite呼叫 出的Rf ACR消息是:charge A-B,即主叫是A,被叫是B。
而这路invite中,被叫号码是ECT Session Identifier URI(即private uri),B号码只可能在refer-by头中携带,这个头并不是信令的强制字段。UE-A完全可以在 收到refer而产生的invite 中并不携带这个头。
那么只能由AS-A来保存refer中的refer-by头,并插入后续收到的invite中并转发出去。这就带来二个需求:
1) AS-A必须能检查收到的每个refer信令,判断它是否用于ECT业务(因为Rerfer也常用于其它业务,比如三方通话或会议)。当判断它是用于ECT业务时,要缓存refer-to头与refer-by头。
2)缓存refer-to头的目的是用于: 当AS-A每收到一个初始invite时,都要检查其req-uri是否匹配了已缓存的refer-to头。如是,则在invite中插入对应的refer-by头( 如果invite中没有这个头或其内容不正确的情况下)。
这样,AS-A(实际上包括了IMS网内所有的补充业务AS)就需要理解ECT业务并对收到的每个refer\invite都作上述处理,影响了性能。但不这么做,计费模型中(B作为Rf ACR消息中被叫号码)这个需求就无法满足。
如果UE-A是PSTN/ISDN用户终端的话,AS-A的角色将由MGCF来做。MGCF的性能也将受到影响(在架构上,MGCF不应该对 补充业务 流程有太多的干涉)。实际组网中,如果AS-B、MGCF是两个不同厂商的话,互通性要求会增加。
代替方案(实用性较强的方案):废除计费模型的要求(指 对于 UE-A发出的新invite呼叫 出的Rf ACR消息是:charge A-B ), AS-A对于 UE-A发出的新invite 出的ACR中带特殊的标识。 AS-B也是如此。这样:计费服务器在根据icid关联AS-A\AS-B\AS-C的呼叫时,可以识别出这是一个因转接产生的呼叫,并将费用计在B的头上。
注1:实际运营中,出于运营商加强管理(即 禁止 不在运营商管控 下的端到端业务)的需要,AS-A,AS-B 当判断出refer不是用于ECT、或会议或其它运营商管理下的业务流程时,AS应该拒绝这个refer请求。
注2:AS-C只需要作为一个普通的补充业务AS而存在,不需要理解ECT业务。
注3:refer-by在AS-B上也作为一个重要信息而需要保证正确性,原因可能是因为 B用户在发起refer之前可能处于多路呼叫中,比如B同时与A、D在二路呼叫中,B发refer把A用户转接给C。AS-B在收到UE-A根据refer产生的新invite时,需要与B用户原有的 A-B 这路呼叫关联起来,refer-by是关键的呼叫查找信息(refer-by中还应该携带GRUU信息).
端到端流程 细节点2:AS-B根据某种信息来判断当前是处于哪个流程中(端到端流程、3PCC流程 其中之一)
在端到端流程、3PCC流程中,UE-B发出的refer在信令上是完全一样的,但AS-B在 端到端流程、3PCC流程 中收到refer后的处理却是完全不一样的。
由于AS-B在端到端流程、3PCC流程中都作为一个重要的角色而存在,AS-B需要有办法识别出当前是在执行哪个流程。
办法可能是 AS-B上预定义的配置或终端上根据配置来携带特定的信令头通知AS-B。
或者根据 “refer流程失败后的异常处理”来认为 端到端流程 优先于3PCC流程,即AS-B总是先按端到端流程来执行。
端到端流程 细节点3:ECT Session Identifier URI 生命期的作用
ECT Session Identifier URI必须有很短的生命期,在超出生命期之后,如果AS-B收到一个被叫号码是这个ECT Session Identifier URI的呼叫,应该拒绝它。
原因是:1),UE-A收到refer后多长时间产生invite?虽然没有标准明确定义其时间,但无疑应该是很快的,否则在用户体验上,UE-B可能因为长期没有收到refer成功的notify通知,而认为转接失败。 2),AS-B在收到refer时,要检查从B到C的呼出限制类业务, 如果新的invite在较长时间后才收到,在这段时间内,可能通过某种接口修改了B的呼出限制业务。如果有生命期概念的话,对于这个新的invite就不需要再判断一次B的呼出限制类业务了(确实标准中也没有作这个要求,可能就是有生命期的考虑)
端到端流程 细节点4:必须有办法能让AS-B实时根据ECT Session Identifier URI识别出这路invite与转接有关。
流程要求:AS-B在收到 UE-A产生的新invite 时,要根据req-uri=ECT Session Identifier URI来定位与原refer对话有关,并找到原对话中缓存的信令头。
这个过程必须是很快(实时),并且不应该让系统产生较多的 全局数据 开销。
如果按照原有的分发机制,要么让 原refer对话存储为全局数据,要么让系统到所有 服务器\板卡\.. 上都去找一次。所以 这个新的分发机制必须仔细设计。
注:
在大容量的电信设备中,多是采用了多服务器、多板卡、多CPU、多存储器、多进程 的设计。不同用户、不同对话的实时数据会存在不同的 服务器\板卡\CPU...上,所以这种设备需要根据网络业务流程的特点来仔细的设计 分发 功能(比如IMS中的隐式注册集、别名组就是分发机制设计的重要基础,而传统网络中并没有类似的概念,所以两种网络对于 一机多号业务 的实现机制可能是不同的),目的是为:1),新收到的业务流 要实时分发到某个 服务器\板卡\CPU.. 上,以保持各服务器\板卡\CPU..的负荷均衡。 2),建立对话过程中和对话后收到的 对话内业务流 能实时分发到 同一个服务器\板卡\CPU.. 上。
以下场景的可靠性与系统性能是较差的:初始invite发到2号服务器上处理,而对话内refer 却发到 3号服务器上处理。这样不仅带来较多的 服务器间 消息交互,各服务器上也可能要存在较多的全局数据,这就失去了 分发功能 的意义。
端到端流程 细节点5:refer所在dialog内同时存在invite usage与refer usage 的需求。
按盲转流程,在UE-B收到refer的202响应时,就发bye,这会终止invite usage,但为了让UE-B继续接收notify,两个终端、AS-A、AS-B、CSCF(也可能有MGCF)上都要维持对话与refer usage的存在。 (可参见 RFC5057 Multiple Dialog Usages in SIP)。这就要求这些设备、终端上要支持 对话内多usage,在数据结构与分发上作较多考虑。
如果UE-B在收到表示转接呼叫成功(terminated)的notify时再发bye,则上述设备、终端不需要支持 对话内多usage。
由终端自己决定如何处理。则如终端只支持后者,则网络设备的要求会简单的多。
端到端流程 细节点6:AS-A对于 UE-A新发起invite ,是否要检查呼出限制? 业务类型判断是否按A与B、还是A与ECT Session Identifier。
标准中未提及上述细节,如果仍按charge:A-B的计费要求来做的话,为了与计费一致可能要作上述处理。
端到端流程 细节点7:refer流程失败后的异常处理。
标准中提及: 当refer发出后,对端回403或503 或特定notify(消息体中指示420),AS-B给业务用户回notify+202,此后按3PCC流程,发invite(盲转)或reinvite(询问转)给 对端。即端到端流程失败时,AS自动转换为3PCC流程与reinvite流程。 A与B在原对话中交换allow时,AS就知道哪个UE是否支持refer(或运营商不愿意把refer发给对端,控制不执行 端到端流程)。则AS不用发refer给对端就可以自行开启3PCC流程。
这可能是说明了 端到端流程 优先于3PCC流程。此处在处理细节上实际上可能无法覆盖上所有业务流程,如哪个响应码表示refer失败。
端到端流程 细节点8:AS如何判断收到的refer是否用于ECT、会议或其它业务?
目前的业务标准中,refer可以用于ECT或3PTY业务。从AS收到的Refer信令看是非常类似的。
区别1:,会议主席将某人加入会议的refer请求中,refer-to是Conference URI,不是非用户PUI。这个refer发出后。对于ECT业务流程中涉及的AS(AS-B,AS-A)来说,AS-B\AS-A收收到refer-to是Conference URI,它必须能了解到这个URI确实是一个会议的URI,而不是一个普通用户的URI( 即盲转流程中的 C的URI)或 ECT Session Identifier URI(如果AS-A按标准要求要识别ECT业务的话)。 除此之外的情况下,refer都应该拒绝,因为它不在运营商管控之下,可能是终端或其它SCP利用了IMS网络的资源进行通信的行为。
而在会议业务中,会议AS如果收到一个refer(refer-to=ECT Session Identifier URI)的话,它也要能判断这个refer是用于ECT,而不是非运营商控制的业务。除此之外的情况下,refer都应该拒绝,原因同上。
ECT的两个AS(AS-A、AS-B)与会议AS都是单独组网的AS,运营商不会允许 非自己控制 的业务流程经过IMS核心网。三个AS必须能判断出每个refer是用于ECT、会议或其它业务。比如判断出refer用于ECT,而用户未签约ECT的话,refer应被拒绝。如果判断出refer不是用于ECT、会议或其它运营商控制下的业务,则这个refer也应被拒绝。
可使用的方法是:1),通过管理手段让三个AS了解到用户PUI、conf uri、ECT session identifier uri的数据,2),直接通过Uri本身的某些特征,如特定号码段来区分上述三种uri类型。3) 或者通过HSS将上述三种URI数据存储并下载到AS中。
区别2:ECT标准中只要求对话内refer。而3PTY标准中提到了对话内refer与对话外refer。但早期的ECT标准与RFC中也提到了对话外refer的用法。AS必须能判断出 收到的对话外refer是用于ECT 的业务场景,此时不符合业务流程,应拒绝之。判断方法类似上面的描述。
端到端流程 细节点9:ECT Session Identifier URI的正确路由
ECT Session Identifier URI必须能作为被叫号码在IMS网络中被正确路由到AS-B。
与 端到端流程 细节点4 结合可见 ECT Session Identifier URI 必须经过仔细的设计。
端到端流程 细节点10(重点):replace流程是否用reinvite流程代替。
在询问转、Conf中使用了replace头。终端在收到一个新呼叫(且含replace头)时,从repalce头中取出dialog id,将本地同样dialog id的另一路呼叫bye掉。 这就是replace呼叫的意义:用一个新呼叫来替换原有的SIP呼叫。
而reinvite流程,则是终端会在原有呼叫中收到一个reinvite,媒体切换成功后从终端角度来说,也实现了与另一个用户通话的目的。
两个流程的设计出发点可能与 业务流程控制方 的设计有关:replace头由另一个终端在信令中携带,常用于端到端流程。 而reinvite流程则常用于3PCC流程,完全由AS控制。
replace头对于网络组网有如下影响:
1,两个终端(被叫有可能是MGCF)都应该支持replace头。标准中又规定了 被叫终端因为不支持replace头而返回失败响应后,AS应该控制转为reinvite的流程。
另外,当被叫是MGCF时(原呼叫发给MGCF1),而新呼叫(refer或invite)发给同样被叫号码(带replace头),这个新呼叫可能被BGCF选择到另一个MGCF2。这样MGCF2上是找不到旧呼叫的,导致这个流程失败。这在标准中也有论述。
解决的办法是让新呼叫发给MGCF1的Contact地址,(实际上也不适用,因为RFC允许B2BUA网元修改Contact)
2, SIP消息经过的各网元可能是B2BUA的,则它们应该把信令中的replace头中替换dialog id。这对各网元设备的要求较高。(replace头在RFC中提出,各个业务RFC中更适用于 网络网元是proxy 的情况,3PCC流程也较少。这可能是因为很多RFC更倾向于 IP网无核心控制 的思路,这种思路适用于proxy网元与replace头)
3,即使各网元都支持替换dialog,仍要求:旧呼叫(invite)与新呼叫(invite或refer)经过的网络路径(指SIP层网元的SIP消息路径)必须是完全一样,否则新呼叫经过的某网元如找不到旧呼叫的dialog时,就会引起dialog id替换失败,上面提到BGCF选择MGCF就是一例。IMS也允许I-CSCF根据 网元能力、负荷分担 的要求选择下一跳的S-CSCF,这也可能引起类似情况(还有:P-CSCF选择S/I-CSCF,AS选择下一跳 I/S-CSCF)。
4,反向replace问题无法解决:业务AS分MO、MT两种。某用户的MO、MT AS经常可能不是同一个。举例:
A发起呼叫到B。经过AS 1(MO侧)、AS2(MT侧)。B发起新呼叫或新refer到A(带replace头),呼叫经过AS3(MO侧)、AS4(MT侧)。 这种组网从IMS业务角度是合理的(用户A的MO AS是AS1、MT AS是AS4)。
按上面的分析,AS3\AS4上没有旧呼叫的dialog id,无法替换它。使得replace流程失败。
解决办法是让新呼叫必须经过旧呼叫的路径(AS1、AS2)。这不但违背了IMS网络的基本原则(MO、MT AS分开),也必须让新呼叫在发出端(如终端或发起侧AS)就能关联到旧呼叫(比如让终端记录旧呼叫的record route头,反放到新呼叫中的route头中,这种办法也需要B2BUA网元替换route头)
注1:在部分业务场景中,replace也无法使用,比如旧呼叫发生了无应答前转业务,新呼叫发给被叫后,被叫会无法在本地找到旧呼叫的dialog id,而导致流程失败。
注2:
3GPP ECT标准通过让AS-B修改refer-to头为自己,保证了UE-A侧发出的新invite一定可以到达自己,这解决了 UE-A到AS-B 侧的部分replace问题(类似于 上述提到的新呼叫发给 MGCF1的Contact地址)。但从 AS-B侧到UE-C 侧的呼叫仍面临上述repalce问题。
注3:标准化组织提出了draft-ietf-insipid-session-id-reqts-00.txt,也许session id头可以代替replace头的原作用,这个头不被B2BUA网元所修改,旧呼叫中产生并端到端的传递它,而新呼叫中可以携带旧呼叫同样的session id,一直透传给被叫终端,被叫终端据此可以bye掉旧呼叫。(这时,即使呼叫中间的信令路径有改变,或B2BUA网元不修改replace头,但两端终端仍是识别session id的,依靠它可以关联两个呼叫)
其它细节:ECT与ECT的嵌套,ECT与会议的嵌套,ECT与限制类业务的嵌套,。。。
比如当ECT AS(AS-B)发现对话内refer的refer-to=conference focus时,这个refer是用于会议呼叫而非ECT业务。此时应拒绝refer。注:前提是ECT AS能知道Conf AS的地址或标识信息。
=============================
3GPP TS 24.605
Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem;
Protocol specification
与3GPP TS 24.147
Conferencing using the IP Multimedia (IM)
Core Network (CN) subsystem;
Stage 3
定义了Conf业务(会议业务,传统网络中也称为三方通话或多方通话)的细节。
CONF标准包括了以下流程
1,建立会议:invite:conf factory uri,或invite:conf uri。 可能带uri list
1.1 主席直接建立会议
1.2 主席位于二路通话或一路通话中,并保持它们,主席建立会议。
1.3 主席直接用conf uri来建立会议。 24.147的5.3.2.3.2,A.3.3图
按PSI触发,在MT侧做业务。
2,加入会议(可由主席邀请,分端到端与3PCC。 也可由AS邀请。也可由成员自已加入会议。)
2.1 3PCC流程:主席发 对话内refer 给AS(req-uri=conf id),refer-to=远端用户,AS产生invite给远端用户。
如会议建立前已有一路通话的话,refer中要带replace头。
2.2 端到端流程:主席发 对话外refer 给远端用户(refer-to=conf id)(当是二方转三方时,这个refer是对话内refer),后者UE收到后,发invite给conf id,以加入会议。
见24.605的A.2.1, 24.147 的5.3.1.4.1, A.4.3.1.2图(是对话外refer)
异常过程:见 24.605的4.5.2.1.2 的note2 与 4.5.2.2A 的最后一句话。 24.628的 4.7.2.9.7
当refer发出后,对端回403或503,AS给业务用户回notify+202,此后按3PCC流程,发invite(盲转)或reinvite(询问转)给 对端。即端到端流程失败时,AS自动转换为3PCC流程与reinvite流程。
A与B在原对话中交换allow时,AS就知道哪个UE是否支持refer(或运营商不愿意把refer发给对端,控制不执行 端到端流程)。则AS不用发refer给对端就可以自行开启3PCC流程。
refer中如带replace也对路径上的B2BUA网元有要求。
2.3 3PCC流程:主席在建立会议的invite中带uri list,AS分别发invite或re-invite(如是二方或一方转三方的话)给各uri。
2.4 (这个流程在24.605中没有提到)AS主动发refer给UE,UE再发invite给AS以加入会议。3GPP 24.147的A.4.3.1.4图、5.3.2.5.5,5.3.2.5.1最后一句
2.5 (这个流程在24.605中没有提到)普通成员主动发invite给conf id, 24.147的5.3.1.4.1
3,离开会议、踢出会议
3.1 主席或成员 主动发bye给AS。主席发bye则会议结束。
3.2 主席踢人:发refer给AS,method=bye. 用refer-to表示踢一个人或所有人(会议结束)。
3.3 AS主动bye用户(由本地管理员触发) 24.147的5.3.2.6.2.1, A.6.4.1图
4,成员订阅会议事件
主席在会议建立时收到conf id时发起订阅。
成员在加入会议后,向conf id发起订阅。
5,BFCP协议(UE与MRFP之间,MRFC与AS未参与) 24.147中 8 Protocol for floor control for conferencing
发言控制的流程:
普通用户a申请发言,-> Flow control controler(即MRFP)
controler 通知 会议主席。
会议主席允许发言 -> controler
controler通知 用户a及会议中其它用户。
Conf业务同样分为端到端流程与3PCC流程。其区别同ECT业务。
Conf业务细节分析
许多细节问题同ECT业务。另外
细节1:Conf factory uri与conf uri的仔细设计,以用于IMS网内路由到会议AS。原因与设计原则同ECT业务。
细节2:端到端流程,普通成员发invite加入会议时,可能存在冒充问题,因为只要知道了conf uri就可以加入会议。如果主席没有订阅的话,就不知道会议中有哪些人。这是一个安全隐患。 可行的方法是:1)会议功能中要求 主席终端 必须订阅会议事件。这样主席用户可以知道哪些人加入了会议。 2) 每当一个用户加入会议,就向会议中所有成员放音,提示xx号码加入了会议。
细节3:replace问题,同ECT业务。
3GPP定义的IMSnbsp;ECT业务与Conf…相关推荐
- 在nsa组网架构中,3gpp定义的nr与epc的接口是什么
原文地址:http://www.samsungcamera.com.cn/ 在nsa组网架构中,3gpp定义的nr与epc的接口是s1接口:nsa非独立组网架构的意思是在此架构下5G必须依赖4G网络来 ...
- ATM高层定义了4类业务,压缩视频信号的传送属于______。B
ATM高层定义了4类业务,压缩视频信号的传送属于______.B A.CBR B.VBR C.UBR D.ABR [分析] ATM高层定义了如下4类业务: 固定比特率(CBR)业务,用于模拟铜线和光纤 ...
- 新解决方案销售之四:定义痛苦或关键业务问题
新解决方案销售读书笔记 1.客户拜访七步框架 2.让对方承认痛苦 究竟如何才能让客户愿意向陌生人透露他公司内的敏感信息呢? 解决方案销售研究指出,如果销售人员能做到以下事项,则客户比较愿意敞开心扉: ...
- tomcat下多个app 不同的图标_5G SA网络切片下,独立APP应用如何自行接入不同网络切片...
S-NSSAI是一个全球标准性定义编码(特别是0-127)是国际的标准,所以该值一定是运营商来定义,通过CSMF下发给NSMF系统,来设置各个子网域的VNF属性. 例如腾讯公司在三大运营商同时开通一个 ...
- 业务架构的定义、特性和方法
引言 业务架构一般不被开发重视,开发人员喜欢追求新技术,而技术是服务于业务的,现在没有一项技术是自娱自乐的,一定要支撑业务,否则没有场景.设计好业务架构要考虑的方面比较多,要做到业务彼此隔离.业务与技 ...
- 「业务架构」定义业务能力-备忘单
业务能力定义了一个业务在其核心做什么.这与"如何"做事或在哪里做事不同.业务能力是业务架构(i)的核心.在进一步讨论之前,让我说这不是一篇关于业务能力或能力映射重要性的文章.如果您 ...
- mbsfn子帧_LTE多媒体广播多播业务关键技术研究
基金项目:国家重大专项(2010ZX03003-004) 随着互联网的迅速发展和大屏幕多功能用户设备的普及,出现了大量移动数据多媒体业务和各种高带宽多媒体业务,如视频会议.电视广播.视频点播.广告.网 ...
- 基于IMS的VoLTE业务
VoLTE: Voice over LTE LTE其实是一种接入核心网的网络技术 IMS就是这种核心网之一. VoLTE是架构在4G网络上全IP条件下的端到端语音方案. -高分辨率编解码技术, 语音质 ...
- 基于SPN的专线业务承载方案
[摘 要]5G时代,垂直行业专线业务是一片尚待开发的蓝海,是未来运营商利润来源的新引擎,但现网PTN只能提供业务间的软隔离,无法满足uRLLC场景的业务承载需求.首先描述了现有承载技术难以满足低时延 ...
最新文章
- Spring Boot持久化的简单实现
- 网站推广期间出现排名异常网站推广专员应如何应对?
- H5 canvas 绘图
- Java编程基础10——面向对象_多态抽象类接口
- LOJ #6669 Nauuo and Binary Tree (交互题、树链剖分)
- VS Code阅读Android源码
- android 自定义 child,Android自定义View
- 线性规划 - 用单纯形法解决LP问题 - (Matlab、Lingo建模)
- Windows 7防火墙阻止了远程桌面连接的解决方法
- FileNet入门学习
- VMware虚拟机如何迁移到阿里云
- 项目中引用Iconfont(阿里巴巴矢量图标)的方式
- 移动直播技术秒开优化经验(含PPT)
- 四、s3c2440 裸机开发 通用异步收发器UARN
- 北航计算机机试13真分数约分
- Eureka健康检查
- 除了搜索,Google还能做什么?(转)
- Hadoop2.7.5集群搭建
- C#,图像二值化(04)——全局阈值的凯勒算法(Kittler Thresholding)及源程序
- java文件下载时文件类型_Java基础之文件下载实现自定义名称和格式类型-java下载文件...
热门文章
- 人生永无止境的意思是什么_《永无止境》中艾迪真的成功改进了NZT吗?
- 集合竞价如何买入_世界上最稳健的抓涨停方法“10分钟集合竞价”选股诀窍,买入直接稳赚10个点,赚到笑...
- 视频的播放的用例设计点
- linux 消息队列_Linux消息队列
- class 原生js获取父元素_JS获取节点的兄弟,父级,子级元素的方法
- 技术提升为管理,最重要的能力是什么?
- codeblock 安装debug调试
- firefox无法打开php,php – CORS无法在Firefox中运行
- 伏安特性曲线实验报告_【鼎阳硬件智库原创 | 测试测量】动手测量电解电容器的阻抗频率特性...
- jpa 原生sql 查询返回一个实体_JPA查询--使用原生sql 并且把查询结果转为实体对象...