VoLTE技术中的会话持续性-ICS,SRVCC,eSRVCC
1.VoLTE技术中的会话持续性-ICS
参考文献：
1，邮电设计技术：移动软交换向m-AGCF演进分析
2，3GPP ICS标准
目录
ICS概念
ICS的用户需求场景
ICS对现网的影响
ICS中的用户终端
ICS中的用户标识
ICS、SRVCC、eSRVCC间的关系
ICS架构图
ICS中的SCC-AS
ICS中的新概念
1，呼叫控制信令、承载控制信令
2，接入域选择ADS
3，T-ADS（被叫侧接入域选择）
4，增强MSC服务器(enhanced MSC,eMSC)
ICS中业务流程
1，注册流程
2，MO侧
3，MT侧
ICS架构方向、实现方案的选择
引入ICS概念后，CS域\PS域\IMS的改造
ICS中的紧急呼叫
ICS中的短消息
================
ICS概念
3GPP IMS最初的设计是利用PS域作用户接入网络，用于进行会话控制和建立会话承载。ICS（IMS Centralized Services，IMS集中业务）对IMS架构进行增强，使CS域也能作为接入网络，用于建立会话承载（由CS域或PS域提供会话控制）。
ICS可视为移动语音业务网络演进的一个中间阶段：
阶段1：CS域与IMS域并列为PLMN的三个域之一。
即：CS域独立作会话承载与会话控制，独立接入业务网络，与PS域接入的IMS 间只有互通关系。
阶段2：CS域演进为IMS域的接入网，提供会话承载功能（由CS域或PS域提供会话控制），业务完全由IMS域提供。即ICS的架构。
由于阶段2中CS域、PS域接入都由IMS域提供语音业务控制，则由于当前接入网络技术的多样性而产生了无线网络间切换（不仅是PS域切换到CS域，不同PS域间，不同CS域间存在这个需求）时的语音业务会话持续性需求，并且需要增强IMS域功能来为
切换提供语音业务会话持续性。
所以：阶段2中：ICS与SRVCC将共存。
阶段3：CS域消亡，ICS也随之废弃。所有终端都统一到LTE无线技术，且均由LTE 承载接入IMS。
阶段3中底层无线网络间的切换对IMS域应该是透明不可见的。
ICS方案要求ICS用户在PS域、CS域接入IMS业务均能得到一样的体验。包括常见的补充业务（如号码显示类、呼叫限制类、呼叫转移类）、Mid-Call业务（呼叫保持/等待，会议、ECT）、业务信息设置（如改变前转号码）（设置业务信息的方式有多种，如使用Ut接口，或CS域接入时使用USSD接口。如传统UE只能用USSD、传统IMS UE可在CS域与PS域接入时均使用Ut接口 )。
3GPP TS 23.292
IP Multimedia Subsystem (IMS) centralized services;
Stage 2
是ICS的框架性协议，描述了各种功能对网元的要求，及涉及的信令流程。
ICS的用户需求场景
用户通过CS域接入的场景至少包括：
1）许多情况下，CS域接入的语音质量较PS域高。
IMS终端当前的PLMN 接入网没有提供PS域，或其PS域不能提供多媒体（比如只能提供语音、不能提供视频）传输能力，或其PS域不能提供可靠的语音业务QOS保护。(LTE 中使用PCC为PS域承载VOIP作出QOS保证，而老的3G尤其是2G 网络的PS域较难提供这种保证。而语音业务的收费模式与习惯要求运营商必须保证语音业务的呼叫质量与接通率）
LTE中，IMS信令是Non-GBA承载的，而VOIP媒体则是GBA承载（QCI=1,最高优先级，时延要求100ms）。
2）CS域传递呼叫控制信令、承载控制信令、媒体时，在安全性上较有保证。
3) 运营商需要给现网2G\3G 用户发展新业务时，不希望继续在CS域的MSC或智能网来开发。由于新发展的用户经常通过LTE接入（IMS提供业务），新旧用户也可以通过2G\3G 接入网络（比如用户有双模单待（WCDMA、LTE 双模)手机)。此时，同时在IMS域与CS域、或智能网同时开发新业务的成本或数据一致性较难保证。
如果同时在IMS、CS域开发新业务，用户的语音及补充业务需要同时在IMS和CS 网络中维护。此时由于用户数据分别存在于IMS和CS网络中，其同步性、业务扩展性和灵活性都受到了限制。用户数据的同步在实施上经常很困难，尤其是IMS设备厂商与CS设备厂商是不同厂商时，用户数据的一致性、业务体验的类似性几乎成为不可能完成的任务（比如：同一个业务在两个厂商设备中，其用户数据格式经常是不同的）（运营商为所有设备商定义通用数据格式经常难以操作）
而当引入ICS之后，用户在CS域网络的旧用户数据继续保持（旧用户业务数据需要一次性割接到IMS网内，仍存在数据格式转换的问题）。新业务数据只在IMS网内维护。虽然仍存在公共用户数据的同步的问题（比如新用户的开户，需要同时在3G HSS\IMS HSS上进行，对BOSS来说，需要双下插数据。当然这也是现网BOSS系统数据接口的常规工作），但由于补充业务只在IMS网内提供，数据同步的工作量将比“同时在IMS、CS域开发新业务”要减少大部分。毕竟用户业务数据比基本用户数据要多得多。好处是统一用户业务数据管理，减轻运营维护的压力。
注：未来3G\4G HSS与IMS-HSS将融合在一起，避免了用户数据在PLMN接入网、IMS域的同时维护的困难。
4）用户可以升级UE到IMS UE、ICS UE（后两者定义见下），也可以不升级UE，仍使用传统手机。
作为接入IMS域的vMSC，可以升级为eMSC，也可以不升级。
5）用户可以选择通过CS域接入，或通过PS域接入。这个选择性在主叫侧、被叫侧均被提供。好处是CS域接入的呼叫质量更高（运营商也可能对于不同接入方式提供不同费率）。
6）非ICS用户、ICS用户允许共存。
运营商可以选择ICS业务推广力度。在初期只迁移部分CS域用户到ICS中，给这部分用户的好处是可以享受到IMS内的新业务。
ICS对现网的影响
ICS为IMS会话提供使用CS媒体承载的机制，通过ICS，用户所有的语音业务都可由IMS 提供。无论通过PS域还是CS域接入，用户会话都可由IMS控制。
ICS方案兼容传统PLMN方案，即：PLMN本地网内用户（也包括漫游用户）是否有可能一部分用户不是ICS用户，它们的呼叫仍在PLMN内路由
原因是：使用了eMSC之后，ICS用户与非ICS可在PLMN接入网内共存，因为HSS签约数据可判断用户是否支持ICS，ICS用户会被eMSC代替发起IMS注册，所以ICS用户发起的呼叫可被eMSC定向到IMS域，而非ICS用户则被eMSC转回MSC路由。
而普通MSC判断是否ICS用户的方法是到IN去查，IN网分配IMRN的方式可能是根据SCP根据签约数据添加接入码，帮助路由到IMS。或直接由SCC AS的gsmSCF功能(VCC架构中定义)分配IMRN。
CS用户漫游到支持ICS的CS域后，仍使用CS网络做业务。
虽然传统MSC接入也被ICS所允许，但传统MSC无法实现与TAS间的I3接口，无法实现mid-call业务。导致后果：ICS用户漫游到不支持ICS的MSCS时，如仍通过camel方式锚定到IMS，但此时将无法实现Mid-Call业务。另一种方案是：由MSC本地提供业务。
即使PLMN本地网内的通话，也会上到eMSC或普通MSC后再发给IMS域的SCC AS锚定。所以锚定功能实际上由MSC+SCC AS共同执行。
这样改变了PLMN网内路由方式，所有本地(visited)MSC的路由都会指向本地网边缘的eMSC或普通vMSC。eMSC一定会把呼叫定向到IMS域，而普通MSC则需要查询IN得到IMRN 后再定向到IMS域。
注1：ICS部署时可能有一个问题：即使主被叫在同一个CS域进行会话，仍要锚定到IMS域进行会话控制和业务触发。不仅信令会有迂回（业务控制信令、CS承载控制信令都经过互联网上的SCC AS），媒体也会有迂回（CS承载控制路径是经过eMSC控制下的CS-MGW），这增加了会话接续时长（主要由于IMS域处于互联网，时延较长）与媒体互通节点的开销（如编解码转换），
只要主被叫中有一个用户是ICS用户（比如另一个用户是传统CS 用户），上述问题就存
在。
普通MSC需要查询IN后才可经过MGCF路由到IMS域，在ICS出现之前已经产生了CS 域通过这种方式接入IMS的方案，称为非锚定方案(对应的锚定方案是指IMS AS直接提供MAP与CAMEL接口，对MSC/SSP来说，IMS AS相当于智能网SCP，这种方案称为锚定方案)。
它的问题在于：GSM的智能网CAMEL协议只能实现一次触发，即IN业务与IMS域不能同时签约。同样，C网智能网协议中用户只能签约一个SCP，不支持多业务触发嵌套。另外许多运营商的PLMN IN现网已经提供了上百种业务，不可能全部放弃或转到IMS网来，PLMN 现网业务与IMS业务需要共存，但实际部署时经常出现业务冲突问题，即一种业务的实现影响了其它业务的实现结果（同样的问题在IMS域内多业务AS之间也存在，有时在解决上通过IFC触发顺序解决）。
IMS中IFC的触发机制远比IN触发机制灵活，一个用户可以签约多个IFC，触发到多个AS，触发顺序按优先级功能，触发条件可按号码、信令和SDP中任何字段来触发（对AS来说，相当于由SCSCF来过滤呼叫），比如按媒体类型触发，实现了精细化控制。
普通MSC呼入时，没有携带接入网信息，MGCF可能不能补充接入网信息，IMS域内TAS 无法知道用户当前是否漫游、及接入网信息，对于BAIC-Roam（漫游出归属PLMN国家后闭锁入局呼叫）业务无法执行。要解决这个问题，可能需要3G HSS与IMS-HSS 之间的交互来取得用户当前的VLR-ID。
对于地域广泛、地区繁多的国家，某个分支A（如省一级）要开展ICS业务时，不但要改造本省的PLMN与IMS网络，还要保证用户漫游到其它分支后，其它分支的PLMN接入网的vMSC能将用户始发呼叫转到Home IMS来。由于PLMN中IN业务的触发是由主叫侧visited 域来控制（即vMSC触发），则A省运营商要保证全国各省的vMSC都要改造，以触发到SCP 去取得路由。
ICS中的用户终端
ICS方案针对的是拥有2G\3G CS域接入能力的UE。在这个方案中，UE也可以具有2G\3G\4G PS域接入能力。但ICS方案的关注点是：UE通过CS域来传输媒体时，UE与IMS 之间的信令传递机制。
引入ICS概念后，根据用户终端功能的不同可以将ICS网络内的终端大致分为以下几类。 1）传统UE：包括2G/3G 中的传统UE，只能通过CS域进行语音呼叫。
2）传统IMS UE：2G/3G/LTE中传统UE，如果所处PS域能提供VOIP语音业务保证（PS 域对于IMS信令、IMS媒体需要提供不同的QOS，而传信令的要求较低），且UE上安装了IMS应用软件。这种UE同时具有CS域、PS域的接入能力。
3）ICS UE：比传统IMS UE更进一步，要求支持ICS UE的能力。
上述终端均为ICS方案所接纳(下文的ICS用户包括了三类终端)，并允许它们在Home域与Visited域接入时均可提供ICS功能。
终端不同，对于ICS方案的实现架构影响很大。有些运营商和厂商倾向于ICS UE。而大部分运营商更关注传统UE、传统IMS UE 的接入。
使用ICS UE后，从业务体验上来说，由于终端能力强大，可能更容易开发新业务（即使从CS域接入）。I1\Gm接口对PS域Qos要求不高，各种复杂的新业务流程引入不需要修改eMSC或MSC，直接升级TAS、SCC-AS与终端升级软件即可。比如转接、三方、接续等操作可通过Gm口传递。部分拥有较强终端定制能力的运营商支持这种方案。
但传统IMS UE当从PS域接入时，即走传统IMS流程时，各种IMS新业务均可使用。而从长期来看，通过LTE接入总有一天会成为主流，ICS UE也将是临时的解决方案。
所以：传统IMS UE在ICS接入的方案，更容易成为当前的主流方案。
ICS中的用户标识
ICS终端、IMS UE仍支持传统的IMS用户标识。
当eMSC收到CS域注册成功的通知时，它会代替终端进行注册，它使用特定的方法来生成用户PUI与PVI（称为ICS专用PUI与PVI），并支持GRUU。为了避免双注册（当用户也在PS域中进行IMS注册时）冲突，HSS中配置了ICS专用PVI，它与IMS PVI拥有相同的隐式注册集PUI（即一个用户的签约数据中有两个PVI，对应同一个隐式注册集，对应同样的业务触发IFC，这让用户不管是从PS域接入，还是CS域接入，都能触发到同一个TAS进行补充业务处理，TAS中将此视为同一个用户的两次呼叫，区别只是地理接入位置、当前接入网不同。）。隐式注册集中也被加入了ICS专用PUI。
这种用户标识的设计，使得SCC AS的Sh接口必须识别PS域发起的IMS注册与CS域发起的IMS注册。
HSS中用户的IMS profile中使用Tel uri作为缺省PUI，它与CS域的C-MSISDN相同。可以支持2G\3G与IMS同号。
ICS、SRVCC、eSRVCC间的关系。
ICS内的切换设计只针对2G\3G CS域内发生切换时对IMS呼叫的影响。（3G的CS域切换到2G CS域时，媒体仍在CS域中承载，但PS域可能丢失，这只影响了Gm接口，不影响会话持续性）
SRVCC针对4G LTE网络（只有PS域）在会话中切换到2G\3G CS域或PS域的流程。（原始需求是：用户在LTE蜂窝内发起呼叫，呼叫中高速移动，并切换到2G\3G 的蜂窝内）。所以要支持SRVCC的话，即意味着部分支持了ICS的功能。
eSRVCC中引入ATCF，ATCF向SCC AS屏蔽终端类型的区别，比如对通过Gm、I1、I2等接口发起的呼叫。则ATCF需要支持ICS中的Gm,I1接口。Gm、I1发起的呼叫，业务控制信令和承载控制信令的合并，由ATCF来实现。
ICS架构图
图：ICS架构
I1、Gm接口：只执行呼叫控制信令，不执行注册功能。注册通过eMSC来发起。
I3接口要求实现“interwork CS signalling”和“service setting”，重点是用于传递mid-call信令与用户状态、用户配置信息。可能基于Ut接口实现。
ICS中的SCC-AS
SCC AS作为Home域的SIP AS存在，是所有ICS用户起呼与终呼的锚定点。方法是通过起呼IFC与终呼IFC。它应该作为起呼iFC中的第一个AS和终呼iFC中的最后一个AS。另外主叫侧或被叫侧的S-CSCF也可能采用PSI终呼过程来转发请求到SCC AS。
SCC-AS接续了ICS用户与远端用户之间的呼叫，它作为B2BUA，两侧的call leg分别称为：接入分支（或称近端分支，local leg，Access leg)：UE和SCC AS之间的呼叫分支。
远端分支（remote leg)：在SCC AS和远端用户之间形成的呼叫分支。在远端分支调用TAS 和其他应用服务器。
SCC AS的功能：
CS访问适配（CAA）：当呼叫控制信令通过CS域传递时，它维护呼叫控制信令流程。 ICS用户代理（IUA）：它控制本端leg的呼叫承载建立（当通过CS承载接入时），即维护承载控制信令流程。当ICS UE使用I1\Gm接口作为呼叫控制信令时，因为SCC AS与本端UE间同时维护了两个会话，IUA会关联两个会话，对远端只体现为一路标准的IMS呼叫。
终呼域选择（T-ADS）：选择ICS用户的接入域，或获取CSRN将终呼发往CS域功能。它会考虑接入域和UE的能力、IMS注册状态、CS域状态、已有的活动会话、以及运营商策略来进行选择。
T-ADS的选择结果是：媒体通过PS域建立、或媒体通过CS域建立并使用Gm\I1进行呼叫控制、或媒体通过MSC(eMSC或普通MSC建立)。（当媒体通过Gm\I1作呼叫控制时，ICS 用户会自行发起CS域的起呼）
在这个基础上，通过接入网选择ICS用户的Contact 地址。
如果UE通过标准MSC Server注册到CS网络，T-ADS获取CSRN以将终呼请求通过CS域传递给UE。
UE T-ADS也可能被执行，甚至与T-ADS同时执行。
ICS中的新概念
与传统IMS架构（或手机通过PS域接入IMS进行VoLTE呼叫）相比。ICS提出以下新概念：
1，呼叫控制信令、承载控制信令
承载控制信令的概念，在IMS与PLMN、PSTN中都是没有的。虽然IMS中的呼叫、媒体是走不同路径，但媒体路径的建立受呼叫信令所控制，媒体层RTP本身也有信令功能，但它与ICS中的承载控制信令的作用完全不同。
也许Nortel、AT&T当初提出这种思路，只是为了只是希望业务增强主要由终端实现，对网络影响要小。但我看来，区分出这两种信令，代表了一种崭新的电信技术演进方向：将呼叫功能区分为两部分：基本呼叫与业务控制、媒体控制。两部分功能走不同的信令路径，分为不同的SIP会话。由SCC AS将这两个会话关联起来。这是呼叫功能细化的一个思路。
呼叫控制信令(或称业务控制信令，Service Control Signalling Path)、承载控制信令（Bearer Control Signalling Path）可分离或合并。
当分离时，
呼叫控制信令的两端是：UE、SCC-AS。允许通过两种接口中的任一种完成。如I1(建议是CS域的USSD信令),Gm（PS域接入时）。针对ICS UE。
此时SCC-AS会同时维护两个SIP会话，一个会话（呼叫控制信令）完成UE的呼叫控制或切换(它在I1或Gm接口完成)。另一个会话完成媒体的交换(通过CS承载控制信令完成）(它的路径是：SCC-AS、eMSC、CS域、手机)。
对SCC-AS来说，需要将两个SIP会话进行关联。
注：I1、Gm接口也用于释放过程。另外，2个SIP会话中，任一个出现异常，都需要SCC AS 释放另一个会话。在切换之后，I1、Gm接口可能丢失，此时仍需要保持会话。
ICS UE的引入带来了信令流程的复杂性。
当合并时，
呼叫控制信令将从用户所处的 visited PLMN或当前接入PLMN 的CS域传递到IMS域内，即与承载控制信令的呼叫路径是一样的。
此时SCC-AS只需要维护一个SIP会话即可。SCC-AS将完全作为B2BUA，会维护远端与近端会话的连接。
注：
注：不管是分离还是合并，当通过CS域接入时，本端用户在 visited PLMN或当前接入PLMN 的媒体总是在CS域承载。
一般所说的“CS域接入”是指用户呼叫的媒体，在所处接入网（PLMN）内这段，总是利用了CS 域传递。此时，用户仍可利用PS域或CS域或USSD来传递呼叫控制信令（PS域承载的传递媒体的QOS要求较高，但传递SIP信令的要求一般可以满足）
三种ICS终端均可以使用普通MSC+MGCF 建立语音承载。
三种ICS终端也可以由eMSC 将媒体SDP带给IMS核心网建立承载。
注：
ICS UE使用I1\Gm接口来进行呼叫控制，呼叫建立流程复杂，建立时间增长。
I1接口使用USSD方式。可能的方式是SCC-AS通过MAP连接eMSC，或通过其它协议（如
短消息SMPP协议）连接USSDC。
2，接入域选择ADS
接入域选择(ADS, Access Domain Selection)（或称起呼域选择）
它指ICS UE（或传统IMS UE)在发起始呼时，基于网络能力及运营商策略来选择是使用CS 承载还是PS承载。
对终端来说，既然CS域、PS域都可以接入IMS（呼叫与注册），那么它作主叫时，也存在域选择的问题。这完全由UE自己完成。
选择因素包括：
- 当前可得到的接入网种类：如PS，PS+CS，CS；
- 当前接入网PS接入是否支持IMS 语音（如IMS voice over PS Session Supported Indication）；
- UE的设置（如IMS PS Voice preferred、IMS PS Voice only、CS Voice preferred、CS Voice only）。
注：ICS UE、传统IMS UE在注册过程时也面临这种选择。上述终端本身是要注册到CS域的，当CS域注册成功后，eMSC会代替用户发起IMS注册。当它们支持PS域时，并且PS域支持IMS语音或视频时，UE应该也从PS域向IMS中进行注册。
3，T-ADS（被叫侧接入域选择）
由于允许终端可以选择PS域、或CS域向IMS进行双注册（另外，通过普通MSC接入时，UE不需要注册）。
那么在被叫侧需要选择一种域呼向用户。此时终端如只在一个域内进行了注册，选择是唯一的。如终端同时从两个域进行了注册，那么选择的策略将比较复杂
T-ADS分两种： 1）完成由SCC-AS来执行T-ADS。 2）SCC-AS先通过呼叫控制信令路径（I1，Gm）呼向终端，由终端来选择一个域把选择结果通过18x响应返回给SCC-AS。在选择完成后，SCC-AS将呼叫发给UE（利用承载控制信令）。
3GPP 29.328 Sh接口中定义了一个参数（T-ADS Information），可以取得UE当前小区是否支持IMS语音的信息，参数值如下：
- IMS-VOICE-OVER-PS-NOT-SUPPORTED (0)
- IMS-VOICE-OVER-PS-SUPPORTED (1)
- IMS-VOICE-OVER-PS-SUPPORT-UNKNOWN (2)
T-ADS需要知道PS域、CS域是否可达（UE reachability for IP），参数值是
- UE-IP-REACHABILITY-MME. Its possible values are:
- REACHABLE (0)
- UE-IP-REACHABILITY-SGSN. Its possible values are:
- REACHABLE (0)
Location Information参数将用于选择CS域呼叫目标。
Location information for CS
Location information for GPRS
Location information for EPS
4，增强MSC服务器(enhanced MSC,eMSC)
它类似于Tispan为固网用户定义的AGCF网元（PES子系统）。eMSC也可称为mAGCF 或m-AGCF（m即mobile)。
AGCF可将固网用户接入IMS（接入网可能改造为：普通电话通过AG\IAD接入。也可能未改造，直接让C5局或C4局通过TG\SG接入AGCF）。
而mAGCF可以将3G\2G CS域用户接入IMS。CS域不需要任何改造（HSS要增强以支持ICS用户参数）。
mAGCF会完成CS域信令到SIP信令的转换。不仅是呼叫信令，它在收到CS域的注册完成通知或位置更新时，会代替用户发起IMS域的注册。
mAGCF会控制CS-MGW，目的是完成CS域媒体和基于IP的RTP流的转换。甚至有TC(Transcoding)功能。
注：eMSC在ICS方案中并非强制使用。
UE也可以通过普通MSC接入IMS，当此时，用户无法完成在IMS域的注册功能，将置为IMS域的强制注册状态。普通MSC完成CS域呼叫信令与SIP invite或refer的转换。而在作被叫时，SCC-AS的T-ADS功能可以选择到CS域呼出到用户。
3GPP 29.292-a10 5.7 Supplementary Service Configuration 中要求eMSC能把USSD配置消息转化为Ut接口的消息发给TAS，然后收到http 响应后发RELEASE COMPLETE给终端。注1：当UE通过PS域接入IMS时，不需要经过mAGCF。
注2：eMSC的使用并不是必须的，它比使用普通MSC的好处是：不需要更改现网的路由路径（不需要智能网帮助路由，即重定向），则呼叫建立更快，运营维护也方便。更易实现用户补充业务集中实现（尤其针对老的2G MSC设备）
注3：当其它网络的非ICS签约用户漫游到eMSC时，eMSC需要Fall back到普通MSC，为用户提供业务。
2.VoLTE技术中的会话持续性-SRVCC
目录
IMS中的会话持续性概念
会话持续性的范围
移动IP、SRVCC实现语音业务切换的思路分析
双模终端的类型
SRVCC架构分析
SRVCC的网元
1，eMSC向IMS发出SRVCC切换请求
2，MME执行VoIP和非VoIP媒体分离功能，并向eMSC发起SRVCC切换
3，HSS新增用于SRVCC的参数STN-SR、C-MSISDN
4，UE要具有SRVCC能力
5，E-UTRAN(LTE接入网)的SRVCC能力
6，UTRAN（HSPA）的SRVCC能力
7，SCC AS负责锚定与切换
8，EATF功能实现IMS紧急呼叫到CS的SRVCC切换
SRVCC业务流程概述
SRVCC业务流程细化
IMS侧的SRVCC呼叫流程（单路呼叫、多路呼叫）
IMS紧急呼叫的SRVCC过程
SRVCC流程的改进思路
E-UTRAN附着过程中与SRVCC有关的参数
E-UTRAN业务请求过程中与SRVCC有关的参数
==============================================================
IMS中的会话持续性概念
IMS有关的会话持续性技术集中在语音业务的会话持续性。要求是：业务中断时间不超过300ms,尽量避免升级或修改传统的2G/3G网络
对于语音呼叫而言，由于用户的呼叫分为MO侧与MT侧，主叫侧与被叫侧都可以发起呼叫。各种切换技术关注的重点是发起切换侧UE（称近端）所在网络（2个接入网与一个核心网)的信令与媒体流程。而远端UE的流程不作为重点，往往只是一个收到媒体切换请求并响应的过程。
语音呼叫连续性（Voice Call Continuity，VCC）很早就被提出，伴随IMS从起始、发展、成熟、演进各阶段都在3GPP 标准中被研究。08年前IMS语音呼叫经常从wifi接入，所以R7的VCC(也称DR VCC)开始仅指wifi与2G\3G CS域间的切换。并且生产出了双模双待的手机（Wlan常是5G频段，2G\3G常是2G频段)，伴以系统侧设备的支持，称为DRVCC或DR-VCC(Dual Radio VCC).
随着LTE的普及，但2G、3G网络仍将长期存在。LTE/EPC不提供CS功能，Voice应用将需
要依赖于IMS。LTE的早期部署将仅覆盖部分人口稠密地区。
用户已满意于2G\3G网络的语音质量与覆盖，运营商与厂商开始研究VoLTE呼叫如何切换到2G\3G的CS域语音呼叫，开始也纳入VCC范围。但业界发现难以生产同时在LTE、2G或3G 同时待机的手机（无法同时支持两个RAT技术）（支持LTE和GSM/UMTS的双模手机很难实现双模双待，不能同时附着到LTE和GSM／UMTS系统上进行收发数据或者进行通话，）人们提出SRVCC或SR-VCC（Single Radio VCC）概念，UE本身支持双模单待，基本的SRVCC 方案允许语音呼叫从LTE侧(或HSPA)的IMS呼叫切换到2G\3G\3GPP2 CS域。各种增强的SRVCC方案允许含视频的多媒体呼叫的切换、反向切换（从3G切换到LTE侧）。
3GPP对原3GPP R7的Dual Radio VCC机制进行了修改，以支持EPC中的这种Single Radio 场景，并称为SRVCC技术，包括E－UTRAN与UTRAN/GERAN之间的SRVCC以及E－UTRAN 与3GPP2 1xCS的SRVCC，还包括UTRAN的HSPA与UTRAN/GERAN的CS域间的SRVCC。
SRVCC方案已比较成熟，MSC server assisted mid-call feature对于语音呼叫中各种补充业务提供了支持。SR-VCC 实际上是个切换过程，要求运营商已经部署了IMS网络。
SR-VCC技术可能在LTE网络部署的前期和中期使用，随着LTE网络的覆盖扩大，SR-VCC 技术的使用逐渐减少直至消亡。
注：原始需求是LTE初期是热点覆盖，而2G\3G是广域覆盖，所以用户在LTE覆盖边缘的语音呼叫持续性很重要。除了SRVCC之外，还有CSFB方案作为SRVCC的有力竞争对手，两种方案受不同运营商、厂商的支持。VoLGA方案已被3GPP放弃。
SRVCC的定义：Single Radio Voice Call Continuity: Voice call continuity between IMS over PS access and CS access for calls that are anchored in IMS when the UE is capable of transmitting/receiving on only one of those access networks at a given time.
CSFB的主要缺点是并未从本质上解决LTE提供语音业务的问题，而且每当用户需要语音业务时，用户在LTE网络下的业务都需要中断、切换或挂起，从而影响用户的体验。频繁的系统间的模式转换由语音业务触发，因此与传统意义上的系统间切换触发条件，例如由于LTE覆盖不好引发的向2G系统的切换不同，这种问题无法通过在网络部署阶段的优化来改善。
对于已经部署或计划部署IMS的LTE运营商（也有CS域现网）来说，倾向于使用SRVCC。而部分LTE运营商不打算通过IMS提供语音业务（定位于纯管道运营商，只提供数据业务），而又有CS域现网用户，那他们会倾向于使用CSFB。
会话持续性的范围
固定电话中没有漫游、移动、切换等要求。而移动网络从最初设计开始，就允许用户在其网络范围内、甚至是有同种无线信号覆盖的地区（允许跨运营商）的移动，由此带来了在会话（分语音会话、数据会话）中进行移动的需求。
用户会话中移动可以包括各种场景，直接影响了设计方案。比如（不限于）
1，会话完全建立后的移动，不分主被叫。
2，会话未完全建立时的移动，比如在被叫侧返回振铃消息期间（因为可以振长达60s)，主叫或被叫用户发生移动，即振铃态切换。
3，跨运营商，单制式的移动。比如2G网络内的移动，包括了基站间切换、MSC间切换、GGSN（数据业务）间的切换。也称系统内切换。
4，多制式的移动（如2G网络移动到3G网络，或反之。如WCDMA切换到CDMA 2000，或反之）。称系统间切换。
5，在引入voip后，wifi（voip)与3G\2G\LTE 间的切换。
6，VOIP呼叫间的切换：如原呼叫在wifi\LTE中执行voip（IMS)，切换到2G\3G 的PS域
继续走VOIP。
7，Voip呼叫与CS域呼叫间的切换。如原呼叫是PS域接入的IMS语音，切换后变为CS 域接入。
8，数据业务的切换：如数据业务从LTE切换到2G\3G的PS域。
9，上述各种场景的组合。
移动IP、SRVCC实现语音业务切换的思路分析
移动IP的思路是：本端用户空闲、或呼叫时发生移动或切换（一般来说，空闲下发生移动，而呼叫中发生切换），由IP层屏蔽移动性，对远端来说，本端的IP地址不变。
上层业务（TCP、基于UDP、TCP、SCTP的应用层协议）完全不可见，业务仍能持续。
原因是：移动前两个主机间建立的TCP连接、UDP连接、SCTP 连接，移动后两个主机上的这些连接仍正常存在。只是移动过程中发生了一些丢包或链路维护消息增多。
对于语音呼叫来说，即切换前后，通话两端手机上的信令连接＼媒体连接不变。即应用层完全感知不到切换。
而SRVCC的思路是：本端用户呼叫时发生移动，允许本端终端的IP地址重新分配。但MSC 会代替终端发起SRVCC切换请求（同时，本端手机与MSC之间的CS域连接也会建立），与SCC AS之间建立一个新的本端呼叫路径，提供一个新的本端媒体地址给SCC AS，SCC AS 会通过媒体切换过程让通话两端的媒体层连接重新建立。
所以：SRVCC中，切换后，SIP层信令连接＼RTP层媒体连接会在原通话两端重建。即应用层感知并参与切换。
双模终端的类型
SRVCC双模单待：某段时间只能支持一种接入网，但允许切换到另一种接入网，即为单待。CSFB双模双待（双收单发）：CSFB方案没有VoLTE与IMS。用户在LTE网络中只进行数据业务，语音业务仍由CS域来做。但CSFB终端并非完全的双模双待，它可以在两种接入网络（LTE、3G CS域）中待机，但只能在3G CS域中接受与发起呼叫。
当这种用户做被叫时，通过EPC网络与CS域间的Gs接口，将语音呼叫回落到CS域来处理。
双模双待（双收双发）：同时使用两种接入技术，并允许同时在两个接入网中进行不同的呼叫。当这种终端普及后，SRVCC与CSFB就不需要了。
SRVCC架构分析
3GPP提出的SRVCC网络架构如下图：
3GPP TS 23.216 V11.6.0 (2012-09) 图 SRVCC网络架构
在SRVCC架构中，新增了Sv接口及I2接口(上图中MSC与IMS之间的接口，它实际上是在ICS方案中定义的）。
MME和eMSC之间提供Sv接口，以支持SRVCC切换处理。
关键的会话转移（Session Transfer）功能在3GPP TS 23.237中定义，有时也称为会话切换功能。
通过上图可见，
1, 切换前，UE的本端呼叫路径（承载路径见Bearer path before HO，信令路径见sip signaling path before HO ）经过LTE的PS域接入IMS。
2,切换后UE的本端呼叫路径（承载路径见Bearer path after HO）经过CS域的承载接入IMS （仍受IMS的呼叫控制，类似ICS)。信令路径在上图中没画，实际上是eMSC发起切换请求到IMS域。切换完成后的呼叫控制信令路径类似于：ICS中，传统IMS UE通过eMSC接入的场景。
注：另一种切换方案是：切换后媒体走3G的PS域。
可见，切换后UE所处网络是支持ICS方案的，本端媒体通过CS域，呼叫业务上移到IMS 控制。
SRVCC的实现基础是：Voice over LTE(LTE+IMS)与ICS(CS域+eMSC+IMS)。SRVCC不要求ICS UE。当然支持SRVCC的ICS UE也可以使用（即：切换到3G后，ICS UE的呼叫可以走I1接口）在ICS方案中：与IMS接口的MSC可以是eMSC（它可以以前的vMSC上升级，或单独新增IWF互通功能网元），也可能只是普通的MSC。但在SRVCC中的MSC只能是eMSC，因为它必须与MME接口，必须能发起切换请求。
SRVCC的终端，对应于ICS方案中的传统IMS UE、ICS UE。
SRVCC的网元
在SRVCC方案，我们关心的几个网元
1，eMSC向IMS发出SRVCC切换请求
eMSC对ICS 中eMSC(3GPP TS 23.292定义)进行了增强。
(1) 处理MME/SGSN从Sv接口发送的针对语音媒体成分的重定位准备过程请求；
(2) ICS功能相关的增强：如果支持ICS功能，并且通过Sv接口接受到ICS flag, 那么MSC Server执行ICS功能。
(3) 根据TS 23.237的定义，调用从IMS到CS的会话切换过程或紧急呼叫切换过程；
(4) 协调CS切换及会话切换过程；
(5) 受理非UE/非用户触发的MAP_Update_Location过程/MAP位置更新流程；(即切换成功后，MSC发给HSS一个位置更新消息)
(6) 紧急呼叫情况下，根据条件发送MAP Subscriber Location Report到GMLC以支持位置连续性。
eMSC可以与切换目标MSC合一，也可以独立存在（有时这称为IWF功能）。
它处于在3GPP UTRAN/GERAN中。eMSC有可能支持SIP，也可能不支持SIP。
2，MME执行VoIP和非VoIP媒体分离功能，并向eMSC发起SRVCC切换
MME需要兼顾语音的SRVCC切换和非语音的PS切换处理（或称：VoIP和非VoIP媒体分离功能）（PS bearer splitting function）。
当UE从LTE（语音呼叫承载在GBR上，数据会话承载在非GBR上，UE上语音呼叫与数据会话可能并存）切换到3G时，语音呼叫切换到CS域（按SRVCC流程），而数据会话切换到PS域（3GPP EPC定义了这种流程，非SRVCC范围）。
切换的发起网元是MME，它对于语音会话（面向eMSC，按SRVCC流程）、数据会话（面向SGSN）要走不同的流程。这就是媒体分离功能的意义。
MME发起SRVCC切换的依据是：SRVCC UE将UE的“SRVCC Capabilities”在LTE附着时传送到MME，MME保存用户能力，并用于SRVCC操作。
如果用户在LTE侧同时处于多路呼叫中，切换过程中，MME、MSC只会选择一路呼叫进行IMS侧、CS侧的媒体切换。其它路呼叫的切换会由SCC-AS来发起。原来多路呼叫间的业务关联，将由SCC-AS通过与MSC之间的mid-call过程来处理。
UTRAN (HSPA) 也可以提供VoIMS，此时切换决策由源侧的SGSN作出(又分为：基于Gn SGSN，基于S4 SGSN 两种场景)。它的角色相当于LTE的MME。
MME具体功能总结如下：
(1) 通过分离PS中的语音承载与非语音承载，执行PS承载分割功能（PS bearer splitting function）；
(2) 针对非语音媒体，根据TS 23.401定义的Inter RAT（多无线技术间）切换过程，在目标小区（无线Cell）处理非语音PS承载；
(3) 针对语音媒体成分，通过Sv接口发起SRVCC切换过程到目标小区（无线Cell），如果是紧急呼叫，携带紧急呼叫指示。无论UE当前使用的语音承载数量（如QCI=1）有多少个，该过程仅触发一次。如果当前有多个语音承载，且仅有其中一路为紧急呼叫，MME需要仅针对紧急呼叫执行SRVCC；
对于SGSN，VoIP可以基于traffic class=conversational和SSD=speech检测出来。
(4) 协调PS切换及SRVCC切换，当两个过程同时存在时；
(5) 当UE处于有限服务模式下（limited service mode），切换过程中，发送设备标识到MSC；
(6) 紧急呼叫情况下，根据条件发送MAP Subscriber Location Report到GMLC以支持位置连续性。
3，HSS新增用于SRVCC的参数STN-SR、C-MSISDN
影响两个接口：HSS – MME (S6a)（针对VoLTE)，HSS – SGSN (Gr)（针对VoHSPA)
与传统的EPC-HSS、IMS-HSS相比，需要存储2个特殊参数STN-SR(Session Transfer Number Single-Radio,会话迁移号)和C-MSISDN（即用户在CS域的用户号码），和可选的ICS Flag
在UE的LTE附着过程中，EPC-HSS会通过插入签约用户数据消息将STN-SR(有时也叫做VDN，这来自于VCC架构)和C-MSISDN传给MME。（在HSS中的STN-SR信息、ICS Flag发生了改变时会通知MME。）
MME在切换过程中会转发它们至eMSC。eMSC在发起向IMS的会话切换时，主叫号码是MSISDN，被叫号码是STN-SR。这个呼叫在IMS内被路由到SCC-AS，然后SCC-AS会用MSISDN 关联到原呼叫，并发起到远端的媒体切换。
当用户签约了VoLTE业务后，IMS侧的HSS（IMS-HSS）会存储用户的IMS用户数据与业务数据。如用户还签约了SRVCC业务，那么IMS-HSS中还会存储STN-SR与C-MSISDN。
当用户在LTE侧发起IMS注册时，SCC A会分配STN-SR，并更新到IMS-HSS上，IMS-HSS 则会通知EPC-HSS并传递STN-SR与C-MSISDN给它。
如果用户被允许在拜访网络(VPLMN)中使用SRVCC（），则HSS将在订阅数据中包含SRVCC STN-SR和C-MSIDN,并发送给MME，MME会在切换时传给MSC。
当STN-SR被修改或者从用户的订阅信息中删除时，EPC-HSS应通知MME/SGSN。
注：STN-SR实际上分两种：STN-SR、vSTN-SR。
EPC-HSS、IMS-HSS在用户进行SRVCC业务签约时会存储STN-SR的初始值。即STN-SR。
允许SCC-AS分配新的STN-SR，并通过IMS-HSS传递到EPC-HSS，然后再更新到MME本地。即vSTN-SR。
vSTN-SR为漫游场景所设计(当用户漫游到异地LTE网络时)。
注：STI：Session Transfer URI Identifier。用于CS->PS、PS->PS接入切换的场景。
许多语音切换流程中都出现了STN标识符，用于PS->CS接入切换场景。比如本文中的STN-SR,E-STN-SR。
在SC标准中可以看到更多的流程。
4，UE要具有SRVCC能力
3GPP SRVCC UE 能执行SRVCC 过程。UE 与E-UTRAN 交互参照3GPP TS36.300 中的处理，与UTRAN （HSPA）交互参照3GPP TS25.331 的处理.。
SRVCC UE 向网络指示本终端的SRVCC 能力。这体现在附着请求消息和TAU(Tracking Area Updates)中。
SRVCC能力作为“MS Network Capacity”的一部分，包含GERAN MS Classmark 3(如果GERAN接入网支持)，MS Classmark2(如果GERAN或UTRAN接入网支持)，Codecs IE(如果GERAN 或UTRAN接入网支持)。
由于网络不一定会支持SRVCC能力，所以MME会在S1 AP Initial Context Setup Request 中包含一个”SRVCC operation possible”指示，意味着UE和MME均有SRVCC功能。
SRVCC UE 支持3GPP TS23.292 中的UE 协助的T-ADS 功能，该功能用于选择在CS 域进行语音的终呼过程。（T-ADS对于SRVCC应是可选的）
5，E-UTRAN(LTE接入网)的SRVCC能力
UE 和E-UTRAN 之间交互，参照3GPP TS36.300 中的处理。
当E-UTRAN 选择目标小区进行SRVCC 切换时，E-UTRAN 需要发送一个标识到MME，表示该切换需要SRVCC。
E-UTRAN 决定邻接小区表基于SRVCC 的指示，或者对特殊的UE 建立QCI=1 的承载。
6，UTRAN（HSPA）的SRVCC能
通知SGSN当前切换是一个SRVCC切换。- 当HSPA 选择目标小区进行SRVCC 切换时，HSPA 需要发送一个标识到SGSN，表示该切换需要SRVCC。备注: UTRAN (HSPA) 假设SGSN 支持SRVCC 功能。
决定相邻小区表基于SRVCC的指示，或对特殊UE建立特殊承载。 - UTRAN 决定邻接小区表基于SRVCC 的指示，或者对特殊的UE 建立Traffic Class = Conversational 和Source Statistic Descriptor = 'speech'的承载。
7，SCC AS负责锚定与切换
在SRVCC方案中，为IMS域新增了SCC AS( Service Centralization and Continuity AS)，它完成切换产生的新呼叫与另一侧旧呼叫的关联功能。它实际与ICS中的SCC AS是同一个网元，可视为ICS中定义的SCC AS增强了切换功能。
SCC AS功能分工如下：
（1）呼叫的锚定
在LTE侧呼叫时，SSC AS为主叫侧第一个触发的AS，被叫侧最后一个触发的AS。
（2）正常切换功能
SSC AS在接收切换指示消息后判断切换消息的合法性、寻找原呼叫、用新呼叫的leg更新远端leg，释放原始呼叫的近端leg。
（3）振铃态切换；
（4）配合eMSC 完成mid-call feature。
SSC AS有计费与监听需求。SCC AS与TAS均执行监听功能是需要的。SCC AS关注切换操作与用户接入域信息(T-ADS功能需要)，这些信息在TAS上可能看不到。SCC AS可以监听到用户的切换操作、按小区监听等。
8，EATF功能实现IMS紧急呼叫到CS的SRVCC切换
EATF（Emergency Access Transfer Function）流程见下
SRVCC业务流程概述
3GPP TS 23.216 V11.6.0 (2012-09)
SRVCC业务流程概述（Overall high level concepts for SRVCC from E-UTRAN to UTRAN/GERAN）
1、E-UTRAN 指示MME 进行SRVCC切换。
切换决策很复杂。要求由Visited的接入网络侧控制而非由UE控制。MME还必须识别到用户当前的GBR承载中正进行语音业务，这在产生SRVCC流程之前就会先影响E-UTRAN 的切换决策：必须切换到支持语音的目标网络去，如有多个目标网络可选时，是选CS域承载，还是PS域承载语音。
接入域选择、终端参数设置，在3GPP EPC标准中有专门的流程。
2、MME发起SRVCC流程，将语音承载与呼叫控制信令切换到MSC Server。非语音承载切换到目的GERAN/UTRAN 的PS域（SGSN) 也被MME执行。
MME从HSS了解到终端支持SRVCC，得到终端签约信息中的SRVCC STN-SR标识，传给了MSC。
非语音的PS媒体成分的切换的执行，是根据Inter RAT切换过程实施的，具体定义在TS 23.401规范中。
MME负责协调PS-PS切换过程中的的前转再定位响应(或前向重定位响应，Forward Relocation Response)以及SRVCC的PS-CS切换的响应。
3、eMSC向IMS域发起SIP会话切换流程（这个时候，MSC应该已经准备好了MGW的媒体）。同时也会向CS域发起承载切换流程（路径从vMSC\eMSC一直到目标小区target cell）。
这两个流程同时操作是缩短切换时延的必须要求，但同时加大了切换失败的可能性。
4、MSC完成CS域承载资源准备后，会通过Sv 接口通知MME(携带了CS切换命令信息)，MME 通知E-UTRAN 指示UE 开始切换。
注意：目标网络的CS域承载建立好后，LTE侧的UE才会开始切换到目标CS域。而此时IMS域侧的会话切换过程可能仍在进行中。
可以认为从MSC收到MME通知后，切换就有两个并发的过程，它们决定了切换时延（过程1比较慢）
过程1，本端向IMS发起的会话切换，包括本端与远端进行的媒体切换:媒体路径：MGW-IP
网络-远端网络（包括了远端的MGW-UE）
过程2，MSC向CS域内部发起的承载建立过程+ UE从LTE侧切换到目标接入网（radio切换）。
Radio之间的切换很快，但是在切换前，需要将CS侧的网络侧通道建立好，最好已经将远端更新好；
SRVCC业务流程细化
3GPP TS 23.216 V11.6.0 (2012-09) SRVCC细化业务流程
从上图看，从第6步到第9步完成后，才完全建立了CS电路。然后才发起到IMS侧的切换（Update remote end。标准中讲第10步在第8步之后开始。
但实际上，MSC在第5步完成后已经创建了MGW上的媒体，完全可以让第6步与第10步同时发起。
在CS电路建立完成后，才会进入第14步的handover过程。
SRVCC切换分成：SRVCC without DTM（无数据业务的切换），SRVCC with DTM（语音业务、数据业务的同时切换）
在CS语音会话结束后，如果UE仍在GERAN中，则UE将通过向SGSN发送一个路由区域更新请求(Routing Area Update Request )来恢复PS服务。更新类型依赖于GERAN网络的操作模式，如果UE在CS语音会话结束后已经返回到E-UTRAN，则UE将通过发送TAU(Track Area Update)到MME来恢复PS服务。MME将通知S-GW和P-GW恢复挂起的承载。
见SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO support。其中包括非语音业务的处理，呼叫流不仅要求eNodeB能够判决目标侧是带有PS切换的UTRAN 还是支持DTM的GERAN，而且要求UE能够支持DTM.
IMS侧的SRVCC呼叫流程（单路呼叫、多路呼叫）
3GPP 23.237-c00 6.3.2.1.4 PS – CS Access Transfer: PS to CS – Single Radio
eMSC在发起向IMS的会话切换时，主叫号码是MSISDN，被叫号码是STN-SR。
4a-1、4a-2、4a-3用于ICS终端在切换后更新Gm接口的呼叫控制信令路径。
4b中SCC AS会释放原LTE侧接入leg。
见
软件系统整体设计方案
技术文件 技术文件名称：系统总体设计方案 版本： 拟制 绿网天下(福建)网络科技股份有限公司 修改记录
目录 1.编写目的 .............................................................. 2.设计依据 .............................................................. 3.术语、定义和缩略语..................................................... .术语、定义 ........................................................... .缩略语 ............................................................... 4.概述.................................................................. .系统目标 ............................................................. .设计原则 ............................................................. .演进规划--待补充..................................................... 5.整体方案 .............................................................. .技术架构 ............................................................. .功能架构 ............................................................. .运行流程 ............................................................. .部署架构 ............................................................. .性能设计 ............................................................. 6.功能详述 .............................................................. .管理平台 ............................................................. 软件列表......................................................... 推荐排行......................................................... 热门搜索.........................................................
信息系统总体技术方案模板
信息系统总体方案
目录 4管理信息系统 (3) 4.1系统体系 (3) 4.1.1系统结构 (3) 4.1.2信息共享和信息接口 (3) 4.2应用架构和模式 (3) 4.2.1应用架构 (3) 4.2.2应用模式 (3) 4.3应用功能设计 (3) 4.4数据采集方案 (3) 4.5网络设计 (4) 4.5.1现状和需求 (4) 4.5.2广域网结构 (4) 4.5.3局域网结构 (4) 4.5.4网络与信息安全设计 (4) 4.6系统配置 (5) 4.6.1配置原则和范围 (5) 4.6.2系统配置能力估算 (5) 4.6.2.1服务器处理能力估算 (5) 4.6.2.2内存估算 (5) 4.6.2.3存储容量估算 (5) 4.6.2.4应用服务器处理能力估算 (5) 4.6.2.5应用服务器数量估算 (5) 4.6.3系统配置建议 (5) 4.7系统平台和运行环境 (5)
4管理信息系统 建设目标： 建设范围： 设计依据： 4.1系统体系 4.1.1系统结构 4.1.2信息共享和信息接口4.2应用架构和模式 4.2.1应用架构 4.2.2应用模式 4.3应用功能设计 4.4数据采集方案 ●数据采集 ●数据量分析
4.5网络设计 4.5.1现状和需求 4.5.2广域网结构 4.5.3局域网结构 4.5.4网络与信息安全设计 (1)应用系统网络访问漏洞控制 (2)数字签名与认证 (3) 数据传输的机密性。 （4）防病毒体系
4.6系统配置 4.6.1配置原则和范围 4.6.2系统配置能力估算 4.6.2.1服务器处理能力估算 4.6.2.2内存估算 4.6.2.3存储容量估算 4.6.2.4应用服务器处理能力估算4.6.2.5应用服务器数量估算4.6.3系统配置建议 4.7系统平台和运行环境
办公自动化系统总体设计方案
办公自动化系统总体设 计方案 第一部分需求分析 现代办公需要先进的现代化办公系统。电子化、无纸化以及协同办公，都已成为提高办公效率，加强管理的有效手段。是市的供电管理单位，每天都有大量的公文往来，同时还有各种会议等管理工作，因此需要一套先进的、高效率的、覆盖全企业的办公自动化软件来代替以往的手工传递作业，提供更好的文件管理功能，充分发挥协同办公的威力。同时也为与世界先进的办公机制接轨打下良好的基础。 一、系统概况 为了满足当前办公业务的实际需求，满足企业现代化发展需要，进一步提高企业办公效率，加快企业信息化的进程，达到增收节支的目的，急须建设的办公自动化系统，使办公自动化系统覆盖从机关到基层的各个单位，使企业围每个人之间都可以通过电子快速、安全地通讯，为企业建立一个安全、强壮的通讯基础设施，并在此基础之上扩充办公自动化系统应用的功能和围，把主要办公业务流程计算机化、网络化，实现文件电子化，无纸办公，形成企业办公网络，从而使工作人员之间可以更快地交换信息、更好地协同工作，提高办公效率，降低企业开支，建立一个采用先进技术的、流程控制完备的、达到国先进水平的办公自动化系统。 为了实现这一目标，办公自动化系统应该采用世界领先水平的办公自动化系统技术和开发工具，IBM的Lotus Notes正是这样一个办公自动化平台。 Lotus Notes是Lotus(莲花)公司的软件产品，Lotus公司在群件（用于工作组协同工作的软件）方面居于世界领先水平，领导着群件的标准和发展。1996年被IBM公司强行收购,耗资30亿美元，成为IBM的子公司。Lotus Notes是全球应用最为广泛的群件产品。到1996年，该软件的用户数已经达到900万个，全球500家最大企业中有423家使用该软件作为办公系统平台，在中国，有超过500家政府和企业级用户，包括国务院办公厅、信息产业部、劳动部、国家信息中心、中国人民保险公司、中国人民银行等。 目前，Lotus Domino/Notes(Lotus Notes 4.6)是Lotus Notes的最新版本，办公自动化系统将采用此版本作为办公自动化系统平台。Lotus公司简介和市场情况见附录B。Lotus Domino/Notes功能概述见附录C。 办公自动化系统应该利用Lotus Notes先进的工作流程自动化技术快速把当前的主要
系统实施阶段的主要内容和步骤是按总体设计方案购置和
1、系统实施阶段的主要内容和步骤是：按总体设计方案购置和安装计算机网络 系统；建立数据库系统；进行程序设计；输入基础数据，进行系统测试；进行人员培训，系统转换和试运行。 2、系统设计的任务是依据系统分析报告和开发者的知识与经验在各种技术和实 施方法中权衡利弊，合理地使用各种资源，将分析阶段所获得的系统逻辑模型，转换成一个具体的计算机实现方案的物理模型，最终勾画出新系统的详细设计方案，提交一个系统配置方案报告和一份系统设计报告。 3、系统分析阶段需要确定的主要内容 开发者对于现有组织管理状况的了解；用户对信息系统功能的需求；数据和业务流程；管理功能和管理数据指标体系；新系统拟改动和新增的管理模型； 提出新系统的各种方案和设想；对所有方案和设想进行分析、研究、比较、判断和选择，获得一个最优的新系统的逻辑模型；编制系统分析报告。 4、总体规划的必要性及主要目的 总体规划是管理信息生命周期的第一个阶段，也是系统开发过程的第一步，它的主要任务是明确“系统是什么”的问题，也就是对目标系统提出完整、准确、清晰、具体的要求。由于MIS开发项目往往是投资巨大、时限较长，对企业现行管理体制冲击较大的工程，因此，在系统开发前必须要进行总体规划，并把它置于战略高度。 归纳起来，总体规划阶段的主要目标可概括为三点：（1）保证信息共享； （2）协调子系统间的工作（3）使系统开发工作有序进行。 5、总体规划的主要内容 总体规划主要是编制指导性和纲领性文件，主要包括：（1）系统总体需求分析；（2）制定一套系统开发的文档规范作为各分系统书写文档的标准； （3）设计系统总体结构；（4）设计系统总体网络结构；（5）初步进行系统所需编码分析；（6）初步完成系统的接口设计；（7）制定系统的安全标准；（8）设计统一规范的系统平台；（9）制定系统运行及维护标准； （10）统一协调系统的开发与实施。 6、管理信息系统的网络计算结构的种类 管理信息系统的网络计算模式大致可划分为四种，即集中式处理模式，文件服务器模式，客户机/服务器模式(C/S)，以及基于Web 的网络计算模式或称浏览器/服务器(B/S)模式。这几种网络计算模式在进行数据处理方面大不相同。
软件系统整体设计方案
技术文件 技术文件名称:系统总体设计方案 版本:v0、1 拟制 绿网天下(福建)网络科技股份有限公司 修改记录
目录 1、编写目的 (4) 2、设计依据 (4) 3、术语、定义与缩略语 (5) 3、1、.................................................................................................................. 术语、定义 5 3、2、......................................................................................................................... 缩略语 5 4、概述 (6) 4、1、...................................................................................................................... 系统目标 6 4、2、...................................................................................................................... 设计原则 6 4、3、...................................................................................................... 演进规划--待补充 7 5、整体方案 (7) 5、1、...................................................................................................................... 技术架构 7 5、2、...................................................................................................................... 功能架构 9 5、3、...................................................................................................................... 运行流程 10 5、4、...................................................................................................................... 部署架构
系统总体设计方案
系统总体设计方案 （1）引言 a.系统简介： 系统名称：基于Silverlight的地图路径分析； 系统目的及功能：应用Silverlight技术的WebGIS二次开发， 实现地图的加载，放大，缩小及路径节点的 分析； 系统建设的组织单位：11地信软件工程第一小组； 系统建设的服务对象：在地图处理过程中，需要用到路径分析 功能，求最短路径，最佳路径的全体人 员； b.参考资料： 《基于Silverlight的WebGIS开发》吴信才著电子工业 出版社 （2）系统总体设计技术方案： a.模块设计： 模块层次功能分解图：地图路径分析 基础功能查询功能空间分析 放大缩小移动图形查询条件查询缓冲区路径分析 模块结构图：输入（地图输入）处理（地图分析）输出（输出结果） b.代码设计：代码是代表事物名称、属性、状态等的符号，一般用数字、 字母或它们的 组合来表示。由于功能比较简单，这里采用顺序代码； c. 输入设计： 输入设备：键盘、鼠标等； 数据的校验方法数据的校验方法：由人工进行（数据类型校 检）和（格式校检）； 出错后的处理方法：机器自动处理，只处理正确的数据，出 错数据待修正后再进行同法处理； d.输出设计：输出设备：电脑屏幕（显示图形数据，具备实时性和人机对 话）； 输出格式：以弹出对话框等形式输出； e.数据库设计说明： 概述： 设计意图：此数据库的设计目的是基于Silverlight
的地图路径分析数据库的开发，并加以完 善，可以投用于路径分析； 设计环境：数据库管理系统 SQLServer2000以上； 操作系统 windows 7； f.模型库及方法库设计：模型库完成对模型的静态和动态管理，并与方 法库之间的接口操作 方法库提供对地图放大、缩小、移动、查询及 分析等； g.网络设计：本系统需联网实时更新信息； h.安全保密设计：此系统是以谷歌地图为基础，并不涉及个人信息等情况， 故不存在安 全保密等问题； i. 评价、验收：系统的功能分为基础功能、查询功能及分析功能，在基础功能上，实现放大缩小及移动，在查询上要求能以图形和条件两个方法查询，再分析上要能进行路径和缓冲区分析； j.实施方案说明书： 实施方案说明 系统名称：基于Silverlight的地图路径分 析； 子系统名称：基本功能、查询及分析； 程序语言：c#； 操作系统：Windows系列等； 开发工具：VS2010，silverlight4； 浏览器：IE6.0或者更高等； 环境支持：.NET2.0以上； GIS平台：MAPGIS 数据库:SQLServer2000以上； 实施计划 实施方案审批：实施方案经组长及本组成员商议完成。
(完整word版)系统方案设计的总体思路
第一章系统方案设计的总体思路 2.1 校园网络系统的构成 校园网络系统由软件、硬件两个部分组成。 软件部分包括应用软件和系统软件。应用软件主要是校园网站上的Internet 应用、教学管理系统（计算机辅助教学系统、网络教学与远程教学系统）、办公管理系统（管理信息系统MIS、办公自动化系统OA）；系统软件主要是服务器操作系统、工作站操作系统、网络设备上的操作系统、网络管理系统以及安全系统。 硬件部分主要由网络布线系统、网络设备、主机（服务器）系统以及各种外设（UPS、投影机、打印机、磁带备份设备等）组成。 下面再谈谈校园网络系统设计的总体思路。 2.2 系统方案设计的总体思路 校园网络系统的设计、实施，按照一切从实际出发，遵循经济实用的原则，依照以下思路进行： 1、总体规划，分步实施，基础设施建设一步到位 考虑到学校资金、学校计算机应用的现状、学校教职员的现有水平以及网络建设和应用系统开发的固有规律，学校网络系统的建设应该分步实施。但是分步实施是在总体规划下的分步实施。没有总体规划，整个系统有可能陷入各个部分相互不兼容和前期投资的极大浪费。基础设施建设，这里主要是指综合布线系统的建设，采用一步到位的办法。因为综合布线系统有它的特殊性，综合布线的材料并不昂贵，且双绞铜线已经发展到六类，可以满足1000M的应用需求，专家预测，铜线的性能基本已经到了物理极限，不会再有什么七类、八类铜线出现了；现有的光缆，其性能也足以满足十年以内各种应用对介质的要求。而综合布线系统的施工费用比较高，在旧的楼房里就更是这样，且对工作、学习、生活有一定的影响。为了尽量减少对学校教职员生活的影响，综合布线系统建设采取一步到
软件开发规范之总体设计方案模板
一．引言 1.1编写目的 本文档作为***与XXXXXXXXXX公司之间就***建立XXXX司（局或单位）XXXXXXXXXX系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为***XXX后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：***方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了XXXXXXXXXX系统项目的软件总体设计思路。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从设计原则、功能设计、数据结构设计等方面描述系统的总体设计情况，然后进一步详细描述系统技术实现策略、项目实施以及待确定的问题。 1.4参考资料 [列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。]示范：―――仅供参考，不具备任何实质性的内容。 《XXX总体需求书》（XXX单位XXX提供） 《XXX需求调研报告》作者：XXX 《设计模式》XXXXXX出版社 《UML用户指南》XXXXXXX出版社
1.5术语、定义和缩写 [列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。] 示范：―――仅供参考，不具备任何实质性的内容。 1)OLTP：On-line Transaction Processing，联机事务处理。 2)OLAP：On-Line Analytical Processing，联机分析处理；是使分析人员、管 理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取, 从而获得对数据的更深入了解的一类软件技术。 二．总体概述 2.1现有系统描述 [简要描述客户现有系统的功能、性能以及其他方面，若客户没有系统，则可裁减。另外，可描述客户现有系统的应用状况以及系统规模、人员使用状况。描述客户对象的应用环境平台，如软件环境、硬件环境、网络环境、通讯状况以及人员计算机使用水平等。] 示范：―――仅供参考，不具备任何实质性的内容。 针对金融快报工作，***以前曾开发过一个C/S结构的系统，后台数据库为SQL Server，开发工具是VB6.0。该系统主要完成以下工作： 1.根据人行各业务司局每日上报的数据传真，将数据补录到系统中。 2.根据上报的数据制作金融快报文档。 3.将金融快报的数据转发到人行时间序列数据库中。 金融快报系统的工作流程如下： 2.2存在问题 [通过上述现状描述，分析现有组织结构、现有系统等方面存在的问题。]示范：―――仅供参考，不具备任何实质性的内容。
系统技术方案
机房环境设备智能测控系统 技术方案 目录 一、机房环境设备智能测控系统综述 (1) 1.1 工程概况 (1) 1.2 设计依据 (1) 1.3 设计原则 (2) 1.4 系统检测指标 (3) 二、机房环境设备智能测控系统简介 (3) 2.1 系统简介 (3) 2.2 系统特点 (4) 三、机房环境设备智能测控系统的结构 (5) 3.1 测控中心（SC） (6) 3.2 测控模块（SM ） (6) 四、本次机房环境设备智能测控系统设计方案 (8) 4.1 温湿度检测 (8) 4.2 烟雾检测 (9) 4.3 温度检测................................................................. 1..0 .
4.4 消防报警检测............................................................. 1 0 4.5 市电电量参数检测......................................................... 1..1 . 4.6 UPS 检测................................................................ 1..1 . 五、机房环境设备智能测控系统的功能特点 (13) 5.1 多功能数据显示........................................................... 1..3 . 5.2 报警管理................................................................. 1..3 . 5.3 曲线查看功能............................................................. 1 (6) 5.4 综合管理功能............................................................. 1 (7) 5.4.1 安全管理............................................................... 1 (7) 5.4.2 个性化管理............................................................. 1 (7) 六、售后服务措施及承诺 (18) 6.1 维护服务定义............................................................. 1 (8) 6.2 技术支持................................................................. 1..8 . 6.3 技术服务承诺............................................................. 1 (8) 七、用户培训计划 (19) 7.1 培训内容................................................................. 1..9 .
系统总体方案设计报告
系统总体方案设计报告 方案设计是设计中的重要阶段，它是一个极富有创造性的设计阶段，同时也是一个十分复杂的问题，它涉及到设计者的知识水平、经验、灵感和想象力等。下面XX给大家带来系统总体方案设计报告，欢迎大家阅读。 系统总体方案设计报告1 本文研究了用PLC控制两台电梯的双电梯并联控制系统的设计方法，论文首先详细叙述了电梯的机械系统、拖动系统和控制系统的主要部件的功能和工作原理，确定了用PLC控制双电梯联动系统的方案。 然后确定了电梯控制系统的基本功能，并根据这些功能设计出了电梯的基本运行控制程序。论文讨论了对两部并联电梯运行的要求，研究了并联调度的原则。 并联电梯控制系统的设计以实际情况为根据，计算出了优化的电梯运行调度方案，达到高效、节能的目的。对我国的电梯市场的设计、研发提供了良好的实验依据。 1. 引言 本课题将在借鉴已有成果的基础上，设计基于计算机+可编程控制器的双电梯联动控制系统。通过合理地利用PLC 的硬件资源和软件资源，进行电梯群控系统的设计来提高电梯的操作灵活及快捷。对电梯的群控问题进行分析研究，以两台电梯的联控逻辑为例，设计基于计算机+可编程控制器的双电梯联动控制系统。通过合理地利用PLC的硬件资源
和软件资源，进行电梯群控系统的设计来提高电梯的安全可靠性和操作的灵活性，对缩短平均候梯时间、减少电梯运行时间具有重要意义，对电梯控制的发展具有促进作用。 本设计的主要研究方式、方法包括： 1.通过研究电梯的运行方式，进行双电梯的逻辑设计。双电梯一般遵守集选规则，即将呼叫信号先进行登记，对与电梯运行同向的呼叫信号逐一应答，当同向指令和召唤应答完毕后电梯可以自动换向。除此以外，电梯并联运行还遵循的相应的调度原则：正常情况下，当电梯使用以后，二号电梯作为忙梯会首先自动上升至第三层待命，一号电梯则作为基站电梯在第一层楼待命。当某层站有门厅呼叫信号时，则“忙梯”立即启动并定向运行去接该层站的乘客。 2.选用西门子S7-300系列PLC作为下位机，构成双电梯的控制系统，电梯逻辑控制系统的控制核心是PLC，哪些信号需要输入至PLC，PLC需要驱动哪些负载，以及采用何种编程方式，都决定着其内部I/O点数的分配，根据PLC的I/O节点使用原则，应留出一定的I/O点以做扩展时使用。 控制程序采用结构化设计，使用西门子配套软件STEP7进行编程设计，构建双电梯联控软件系统。 2. 双电梯联控的总体方案设计 电梯的结构与工作原理 电梯是垂直方向上运行的运输设备，由机械和电气两大
软件系统整体方案设计设计
. . . . .. . 技术文件 技术文件名称：系统总体设计方案 版本：v0.1 拟制 绿网天下()网络科技股份有限公司
修改记录
目录 1.编写目的 (5) 2.设计依据 (5) 3.术语、定义和缩略语 (6) 3.1.术语、定义 (6) 3.2.缩略语 (6) 4.概述 (7) 4.1.系统目标 (7) 4.2.设计原则 (7) 4.3.演进规划--待补充 (8) 5.整体方案 (8) 5.1.技术架构 (8) 5.2.功能架构 (10) 5.3.运行流程 (11) 5.4.部署架构 (12) 5.5.性能设计 (12) 6.功能详述 (14) 6.1.管理平台 (14) 6.1.1.软件列表 (14) 6.1.2.推荐排行 (14) 6.1.3.热门搜索 (15) 6.1.4.用户管理 (15) 6.1.5.用户标签 (16) 6.1.6.数据统计 (16) 6.1.7.软件审核 (17)
6.2.客户端应用 (17) 6.2.1.APP应用 (17) 6.2.2.搜索 (18) 6.2.3.个人中心 (18) 7.接口说明 (20) 7.1.内部接口--待补充 (20) 7.2.外部接口 (20) 8.开发和运行环境 (21) 8.1.硬件环境 (21) 8.2.软件环境 (21)
1.编写目的 本文件阐述了绿网市场系统的软件总体设计、系统运行配置与应用方式以及使用的关键技术等。 本文件适用于绿网市场系统的开发研制工作。 2.设计依据 依据产品部输出的《绿网市场 1.0.rp》文档中阐述的产品功能，进行对应的技术方案输出。 参考业内主流WEB系统架构方案，结合公司产品实际业务情况、功能演进规划，进行技术架构设计和演进规划。
应用系统总体设计方案模板
应用系统总体设计 第1章项目概况 1.1 建设背景 概述工程立项批复情况和主要建设内容，本子系统项目在建设内容中的定位 1.2 现状及存在问题 概述本部分业务运行现状、信息系统建设现状（结合信息系统现状调研表调研：已有系统建设建设方式（全国统建/地方自建/部门自建等）、功能范围、技术架构、开发平台、数据库、数据存储情况；已有系统集成要求，升级、改建、废弃，数据迁移等。 1.3 建设目标 归纳本应用建设要达成的业务目标（政务目标—对社会公众的作用；管理目标—对业务管理的提升）、信息化目标（如：实现应用系统覆盖四级、两级部署等） 1.4 建设内容 分小标题介绍各项应用系统开发内容，应考虑到应用模块、应用覆盖（覆盖用户层级）、数据库建设、集成要求（应用支撑软件、与本工程其他系统集成，与已有系统集成）等内容 1.5 术语及定义 对本业务相关的特定业务术语和信息系统术语定义（可选） 1.6 设计依据 列出本应用设计相关的业务文件、政策法规以及专用技术标准、规范（通用的设计依据如可研、初步设计等已列出的依据文件） 第2章业务需求分析 （业务概述，可选） 2.1 组织架构 与本业务相关的组织架构图，各部门（处室）职责和业务范围（可以用表格方式体现部门、处室、业务范围），可参考用户提供或政务公开的业务文件。 2.2 系统用户 用户层级（中央、地方、用户部门）和用户量 2.3 业务功能分析 简述业务功能，可参考初步设计相应详略程度，根据调研情况进行增补、调整 2.4 业务流程分析 2.4.1 业务结构 本应用业务结构树状图（业务项层次图），如有总体流程画出顶层总体流程图，业务结构按业务口径划分，不一定与子系统划分一致。 2.4.2 <业务项名称>
信息系统总体设计方案
目录 第一章前言 (5) 1.1 设计思想 (5) 1.2 几个术语 (5) 第二章总体目标与设计原则 (7) 2.1 总体目标 (7) 2.2 设计原则 (7) 第三章需求分析及功能设计 (9) 3.1 子系统划分 (9) 3.1.1 质量管理子系统 (9) 3.1.2 企业管理子系统 (9) 3.1.3 科研管理子系统 (10) 3.1.4 物资管理子系统 (10) 3.1.5 文件管理子系统 (10) 3.2 系统流程分析 (11) 3.2.1 系统总体岗位划分 (11) 3.2.2 质量管理业务流程分析 (17) 3.2.3 企业管理业务流程分析 (22) 3.2.4 科研管理业务流程分析 (24) 3.2.5 物资管理业务流程分析 (30) 3.2.6 文件管理业务流程分析 (35) 第四章系统总体设计 (40) 4.1 设计思想 (40) 4.2 系统架构 (40) 4.2.1 B/S/D架构的优势 (41) 4.2.2 B/S/D结构中各部分的分工 (43)
4.3 可定制的任务流控制管理 (44) 4.3.1 岗位与角色的划分 (44) 4.3.2 数据库的岗位字段的设计 (44) 4.3.3 任务定制的设想 (44) 4.4 以岗位为依据进行严格的权限管理 (44) 4.5 实现文档电子化管理 (45) 4.6 I NTERNET增值服务 (45) 4.7 统一的后台数据平台 (45) 4.8 通过XML语言实现I NTERNET上的数据交换 (45) 第五章应用软件设计 (46) 5.1 应用软件的设计思想 (46) 5.2 软件系统总体架构 (46) 第六章关键技术介绍 (48) 6.1 基于B/S/D三层体系结构的运行环境 (48) 6.2 数据后台M Y SQL的技术特点 (49) 6.2.1 MySQL的定义 (49) 6.2.2 主要特征 (49) 6.2.3 稳定性要求 (50) 6.3 JSP技术－跨平台的网络开发语言 (50) 6.4 J A V A技术的应用 (51) 6.4.1 Servlet技术－灵活的服务器端应用程序 (51) 6.4.2 Java Apple技术－实现统计数据在网页上的动态显示 (54) 6.4.3 Java Beans技术－组件开发概念 (54) 6.5 通过XML语言实现I NTERNET上的数据交换 (54) 6.5.1 XML会带来什么 (54) 6.5.2 XML的应用 (55) 6.6 采用基于构件的面向对象的设计方法 (56) 6.7 M ICROSOFT S ITE S ERVER站点管理及分析统计技术 (56) 6.8 开发工具 (57)
2019最新智慧交通总体技术方案
2019最新智慧交通总体技术方案 目录 一、系统架构 (3) 二、综合管理平台 (10) 2.1综合运输监管系统 (10) 2.2行业监督管理系统 (18) 2.3安全生产监管系统 (23) 2.4固定资产管理系统 (27)
2.5电子监察系统 (28) 2.6行政执法系统 (34) 三、公众服务平台 (36) 3.1智能手机交通信息服务 (36) 3.2出行服务系统 (36) 3.3在线呼叫系统 (39) 3.4联网售票系统 (41) 3.5停车场诱导系统 (44) 3.6物流信息系统 (45) 四、智能监控平台 (48) 4.1视频监控系统 (49) 4.2卫星定位监控系统 (57) 4.3交通流量监控系统 (59) 4.4可变情报板 (59) 4.5移动执法装备 (60) 五、三大保障体系 (61) 5.1安全保障体系 (61) 5.2标准规范保障体系 (62) 5.3运维保障体系 (62)
一、系统架构 ***“智慧交通”建设应紧紧围绕“智慧交通”的建设思路，结合行业部门针对智慧交通发展的指导性意见，构建交通局“智慧交通”。将整个智慧交通划分为5个层次。 第一层为感知体层，其主要负责信息采集，主要建设内容包括视频监控摄像头、卫星定位设备、交通流量监测设备、船舶动态管理系统、隧道监控设备； 第二层为传输层，其主要负责各体系之间数据及视频信息的传输，主要建设内容包括智慧交通专网、视频光纤通道和CDMA/GPRS/3G无线通信网络。 第三层为基础层，主要负责数据的存储、计算、转发。
主要建设内容包括机房、主机及存储系统、网络及安全设备、基础软件、指挥中心场所。 第四层为支撑层，主要负责为应用层提供基础的服务支撑能力。主要建设内容包括交通地理信息系统、身份及权限管理系统、数据交换系统。 第五层为应用层，是本期“智慧交通”的主要建设内容，主要包括综合管理平台、公众服务平台、智能监控平台、应急指挥平台共四个平台。 1.1短信系统 实现短信的收发；通过统一的短信服务代码对公众提供短信类信息服务，实现与公众的交流；实现对各个短信应用系统的配置维护；通过简单的配置实现与业务系统的对接；提供直观有效的监控手段，实现对平台，对各个短信应用有效性的监控。 系统支持通知类和交互类两大类短信内容。允许部署的各应用系统通过本短信应用支撑平台的相关接口进行短信收发的操作，也允许通过短信应用支撑平台使各应用系统与短信发起人之间进行问答式的交互过程并将最终结果反馈给短信发起人的过程。具体功能如下： 1）应用系统的短信发送和接收提供支撑服务。 （1）提供标准简捷的接口与已有IT系统连接，方便进
内部DSMP系统总体技术方案
内部总体技术方案 拟制：Carlinshu 日期： 审核：日期： 版本号： 腾讯科技（深圳）有限公司
目录目录错误!未指定书签。 背景错误!未指定书签。 概述错误!未指定书签。 范围错误!未指定书签。 引用标准错误!未指定书签。 术语和定义错误!未指定书签。 符号和缩略语错误!未指定书签。 总体架构设计错误!未指定书签。 设计原则错误!未指定书签。 产品关联性设计原则错误!未指定书签。 产品依赖性设计原则错误!未指定书签。 设计目标错误!未指定书签。 路标规划错误!未指定书签。 系统需求错误!未指定书签。 系统软件需求错误!未指定书签。 系统硬件需求错误!未指定书签。 系统功能需求错误!未指定书签。 系统性能需求错误!未指定书签。 系统总体架构错误!未指定书签。 系统物理架构错误!未指定书签。 系统逻辑架构错误!未指定书签。 关键技术分析错误!未指定书签。
业务模型分析错误!未指定书签。 目标用户错误!未指定书签。 用户入口错误!未指定书签。 收费策略错误!未指定书签。 产品依赖关系错误!未指定书签。 典型业务过程错误!未指定书签。 用户模型分析错误!未指定书签。 用户基础信息错误!未指定书签。 用户操作信息错误!未指定书签。 用户流量信息错误!未指定书签。 系统模型分析错误!未指定书签。 性能容量分析错误!未指定书签。 总计错误!未指定书签。 负载均衡分析错误!未指定书签。 负载均衡策略错误!未指定书签。 异地分布策略错误!未指定书签。 容灾备份分析错误!未指定书签。 部署方案错误!未指定书签。 风险分析及规避措施错误!未指定书签。 硬件故障错误!未指定书签。 软件故障错误!未指定书签。 备选方案错误!未指定书签。
软件开发规范之总体设计方案
一．引言1.1编写目的 本文档作为***与XXXXXXXXXX公司之间就***建立XXXX司（局或单位）XXXXXXXXXX系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为***XXX 后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：***方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了XXXXXXXXXX系统项目的软件总体设计思路。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从设计原则、功能设计、数据结构设计等方面描述系统的总体设计情况，然后进一步详细描述系统技术实现策略、项目实施以及待确定的问题。 1.4参考资料 [列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。]示范：―――仅供参考，不具备任何实质性的内容。 《XXX总体需求书》（XXX单位XXX提供） 《XXX需求调研报告》作者：XXX 《设计模式》 XXXXXX出版社 《UML用户指南》 XXXXXXX出版社
1.5术语、定义和缩写 [列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。] 示范：―――仅供参考，不具备任何实质性的内容。 1)OLTP：On-line Transaction Processing，联机事务处理。 2)OLAP：On-Line Analytical Processing，联机分析处理；是使分析 人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互 地存取,从而获得对数据的更深入了解的一类软件技术。 二．总体概述 2.1现有系统描述 [简要描述客户现有系统的功能、性能以及其他方面，若客户没有系统，则可裁减。另外，可描述客户现有系统的应用状况以及系统规模、人员使用状况。描述客户对象的应用环境平台，如软件环境、硬件环境、网络环境、通讯状况以及人员计算机使用水平等。] 示范：―――仅供参考，不具备任何实质性的内容。 针对金融快报工作，***以前曾开发过一个C/S结构的系统，后台数据库为SQL Server，开发工具是VB6.0。该系统主要完成以下工作： 1.根据人行各业务司局每日上报的数据传真，将数据补录到系统中。 2.根据上报的数据制作金融快报文档。 3.将金融快报的数据转发到人行时间序列数据库中。 金融快报系统的工作流程如下： 2.2存在问题 [通过上述现状描述，分析现有组织结构、现有系统等方面存在的问题。]示范：―――仅供参考，不具备任何实质性的内容。
MD380总体技术方案演示教学
总体技术方案
产品总体技术方案编制的说明： 1、产品总体技术方案的制定及更改控制： 在计划阶段，系统工程师（项目经理）组织相关人员根据产品规格书，并在考虑成本分析和资源计划要求的情况下，进行系统设计，编制产品总体技术方案。经过评审的产品总体技术方案必须归档并纳入更改控制。在开发的后续阶段，如有必需，产品总体技术方案也会被更新，但必须经过系统工程师审核，召集系统组或总体组评审，由总体办备案。 产品总体技术方案的每一次更改，应由系统工程师进行一次版本升级和发布，保证项目组及相关部门使用的总体技术方案为有效版本。 2、产品总体技术方案的内容要求： 产品总体技术方案包括对产品的名称和型号、系统组成和接口关系、主回路初步设计和关键器件选型、系统测试方案、整机结构工艺方案、单元的技术规格、EMC 、防护和可靠性方案的设计以及存在的风险进行全面描述。 产品总体技术方案的描述应该全面、清晰，各单元之间接口关系的定义只能有唯一的解释。总体技术方案的内容应明确产品的规格书提出各项要求的实现方式或过程。单元的规格描述应按产品规格书描述的方法进行。 总体技术方案不应再描述实现单元规格的方式或过程，以及单元内部的接口关系，这些将在单元的设计中描述。 3、产品总体技术方案的用途：产品总体技术方案是产品开发过程中最重要的文档之一。它 将作为开发活动任务分解的依据，各个分解单元概要设计的依据和实现的目标，也将作为开发计划和单元测试验收的依据，还将作为产品宣传、产品维护、技术培训、技术交流以及技术积累的资料来源。 4、保密要求： 产品总体技术方案属于机密文件，所有文档的创作者及使用者都负有保密责任。 目录 1、设计背景 (4) 1.1 总体技术方案编制的依据 (4) 1.2 总体技术方案描述的产品名称和型号 (4) 1.3 引用的标准和规范 (6) 1.4 缩略词和术语定义 (6) 2、电气方案设计 (7) 2.1 系统原理 (7) 2.1.1 系统原理图.......................... 错误！未定义书签。 2.2 系统架构 (7) 2.3 系统组成 (8) 2.3 系统接口 (8) 2.3.1 主回路端子 (8)
智能化系统设计方案(整体)-最终版
*** 智能化系统技术方案 <一期、二期综合设计> 设计单位： 设计日期：
目录 第一章系统综述 (4) 1.1项目设计的基础和依据 (4) 1.2项目设计的原则 (4) 1.3项目设计范围 (7) 第二章技术重点及规划说明 (10) 2.1设计思想 (10) 2.2目标定位 (10) 2.3技术重点及建议 (11) 第三章闭路电视监控系统 (13) 3.1概述 (13) 3.2需求分析 (13) 3.3设计说明 (14) 第四章周界报警系统 (43) 4.1概述 (43) 4.2需求分析 (43) 4.3设计说明 (43) 第五章可视对讲门禁系统 (53) 5.1概述 (53) 5.2需求分析 (53)
5.3设计说明 (55) 第六章车辆管理系统 (73) 6.1概述 (73) 6.2需求分析 (74) 6.3设计说明 (74) 第七章安保巡更管理系统 (86) 7.1概述 (86) 7.2需求分析 (87) 7.3设计说明 (87) 第八章机房工程与防雷系统 (94) 8.1概述 (94) 8.2需求分析 (94) 8.3设计说明 (94) 第九章室外管网系统 (102) 9.1概述 (102) 9.2需求分析 (102) 9.3设计说明 (103) 第十章公共广播系统 (109) 10.1概述 (109) 10.2需求分析 (110) 10.3设计说明 (110)
第一章系统综述 1.1项目设计的基础和依据 作为智能化建筑的系统服务者，我们不是凭空作业，我们的工程设计有着坚实的基础和依据。这些基础和依据主要有如下方面： 1.2项目设计的原则 1.2.1先进性 充分考虑信息技术和信息需求的迅速发展的趋势，在技术上应具有一定的超前性，采用国际或国内通行的先进技术，以适应现代科学技术的发展。总体设计要一步