Modulation
一个载波，包含了振幅、频率、相位。而若以振幅变化表示位元变化，称之为ASK(Amplitude Shift Keying)，
若以频率变化表示位元变化，称之FSK(Frequency Shift Keying)，
若以相位变化表示位元变化，称之PSK(Phase Shift Keying)[1] :
以上归纳如下:
BPSK/QPSK
由[2-3]可知，WCDMA 在图)，
因为Uplink 的速率为64 kbp 采用较简单的BPSK 调变机制QPSK ，所以QPSK 的频谱效
然而由前述可知，PSK 在动的，而非固定不变的，的带外噪声，对相邻频率Leakage Ratio)的测项，来测Discontinuity 的测项，来测
在发射端与接收端，分别采用BPSK(左图)与4 kbps ，而Downlink 的速率为384 kbps ，因此在变机制，而接收端采用较复杂，但较能提升Da 频谱效率是BPSK 的2倍。 在位元转换时，其相位不连续，这使得其讯号，因此对于PA 及LNA 的线度要求大，同时频率造成干扰，因此在发射端，有ACLR(Adjace 来测试是否会对其它用户造成干扰，以及来测试信号两个相邻Slot 之间的相位差
[1-
因此WCDMA 在发射端的Pulse shaping ，采用RRC (Root -Raised-Cosine)技术，来抑制带外噪声 :
上图分别是RRC 在时域与频域的波形，而α会决定其频域上所占带宽大小，可用下式做说明 :
0(1)W W α=+ 01α≤≤
W 称之为Nyquist 带宽，而0W 为实际上所占用带宽，α则是Roll-off Factor ，其
值大小会决定所占带宽大小，α越小越好，最理想情况是0，即0W 等同于W ，最坏情况是1，即0W 为2倍W 。而WCDMA 的α为0.22
而接收端方面的Pulse shaping，也采用RRC，来改善ISI (Inter Symbol Interference)，进而提升BER[2-3]。
在无线传输过程中，ISI (Inter Symbol Interference)是很难避免的讯号失真现象，假设有组101101的讯号序列，以无线方式传送出去，
尚未传送时，每个Symbol都在各自归属的Time slot内，然而在传送过程中，受到外界干扰，导致Symbol的能量会泄漏到其他的Time slot，影响其他Symbol，该现象即ISI，如下图:
虚线为传送讯号，绿色为接收讯号，做一番比较，如下图:
可以发现讯号明显失真很多，因此需利用RRC将ISI的效应降低，进而降低失真度，以提升BER。
引起ISI的原因有许多，其中原因之一，便是来自Group Delay，所以若发射端的SAW Filter，其Group Delay过大，则可能会造成EVM劣化[2]。
而若接收端的SAW Filter，其Group Delay过大，则可能会造成BER上升[3]。
GMSK
而GSM采用的是GMSK调变技术，是由FSK演化而来的。FSK若没有保证相位连续措施的话，其相邻位的相位也将不连续，这使信号功率谱扩展，对相邻频率的信道形成干扰。因此为了使主频之外带外噪声衰减速度快，则信号的相位就必须要连续[4]，因此便产生了MSK(Minimum Shift Keying)，而Minimum指的是最小的调变指数:
由下图可知，调变指数愈高，其所产生的带外噪声就越强，
因此要尽量使调变指数降低，才能尽量降低对邻近通道的干扰，而MSK的调变指数为0.5。
MSK是CPFSK(Continous Phase FSK)的一种特例，它能够产生恒包络、连续相位信号，且在带外的频谱分量，比BPSK 衰减的快，这表明MSK 信号功率谱密度占的频宽比BPSK 信号窄，比较适合在窄信道中传输，对邻道的干扰也较小，因此由于MSK恒包络的特性，所以大大降低对电路的线性度要求，同时也因为所占频宽窄，因此提高了频谱效率，这些特点都使得MSK适用于移动通信。
然而，在一些通信场合（例如移动通信），对信号带外辐射功率的限制是十分严格的，比如，必须衰减70~80dB 以上。MSK 信号仍不能满足这样苛刻的要求，需再更进一步抑制带外噪声，GMSK(Gaussian filtered Minimum Shift Keying )就是针对上述要求提出的。
由上图可知，MSK虽然使相位变连续了，但转折处有尖角，这使得带外噪声还是很高，所以透过高斯滤波器，将相位变化变平滑，进一步降低带外噪声。
GMSK的实现，是在MSK调制器之前，加入一高斯低通滤波器。也就是说，用高斯低通滤波器作为MSK 调制的前置滤波器，这与WCDMA的BPSK/QPSK 所采用的RRC不同。
由下图可看出，GMSK对邻近通道的干扰，确实比MSK来的小。
而图中的BT，则是定义如下:
分子为高斯低通滤波器的3 dB带宽，分母为Bit Rate，若Bit Rate 为9.6 kbps，而3 dB带宽为2880Hz，则BT为0.3[7]。
而由上图也看出，BT越小，Noise Floor越小。因此BT若越大，则带外噪声与Noise Floor也跟着越大，而BT无限大的GMSK，则会退化成MSK。
虽然BT越小，则带外噪声与Noise Floor也越小，
但由上图可知，BT越小，则越会有ISI的问题，
进而导致BER变差:
换句话说，带外噪声与Noise Floor的改善，是牺牲BER所换来的，因此必须取一个适中的值，使带外噪声与BER都能尽量兼顾到，而GSM的BT为0.3。
Reference
[1] Digital Modulation Techniques in Mobile Communications
[2] WCDMA零中频发射机(TX)之调校指南与原理剖析
[3] WCDMA之零中频接收机原理剖析大全
[4] 恒包络连续相位调制技术
[5] 移动通信中的调制技术
[6] GMSK数字调制方式及其性能分析
[7] Practical GMSK Data Transmission
系统对接设计 1.1.1 3、7、3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准: 本系统采用SOA体系架构,通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享与集成,因此SOA体系标准就就是我们采用的接口核心标准。主要包括: 服务目录标准:服务目录API接口格式参考国家以及关于服务目录的元数据指导规范,对于W3C UDDI v2 API结构规范,采取UDDI v2 的API的模型,定义UDDI的查询与发布服务接口,定制基于Java与SOAP的访问接口。除了基于SOAP1、2的Web Service接口方式,对于基于消息的接口采用JMS或者MQ的方式。 交换标准:基于服务的交换,采用HTTP/HTTPS作为传输协议,而其消息体存放基于SOAP1、2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作,服务数据与服务操作采用WSDL进行描述。 Web服务标准:用WSDL描述业务服务,将WSDL发布到UDDI用以设计/创建服务,SOAP/HTTP服务遵循WS-I Basic Profile 1、0,利用J2EE Session EJBs 实现新的业务服务,根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准:使用没有扩展的标准的BPEL4WS,对于业务流程以SOAP服务形式进行访问,业务流程之间的调用通过SOAP。 数据交换安全:与外部系统对接需考虑外部访问的安全性,通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准:制定适合双方系统统一的数据交换数据标准,支持对增量的数据自动进行数据同步,避免人工重复录入的工作。 1.1.2 3、3、8接口规范性设计 系统平台中的接口众多,依赖关系复杂,通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准与接口
HIS系统中各类卡接口应用设计说明 1.卡应用结构 主应用：现有的作用模块都是主应用，在需要应用卡的应用程序中，留有卡的适当接口，比如“读卡”按钮，通过这样的接口（或者说是操作卡的收段）来调用“卡接口”中提供的调用函数实现对卡的各种操作； 卡接口：卡接口是一个程序模块，在这个模块中可以定义卡驱动的api函数给应用系统使用；定义函数wf_read()，wf_write()提供给“主应用”使用；函数wf_read()\wf_write()，调用卡驱动的api函数，根据不同卡的读写特点开发程序，主要是处理异常及读写流程； 读卡器驱动：读卡器驱动由其设备供应商提供，一般来说，各个厂商的读卡器驱动都不尽相同，所以每遇到一个不同厂商的设备后，首先需要详细了解产品及相关资料的情况；读卡器驱动一般是dll，其中打包了一系列的函数，这些函数是要在“卡接口”中定义声明使用的； 2.卡应用的数据基础 医院中应用卡，往往是要贯穿到各个业务部门科室，而卡，在这里仅仅起到“信息提示”的作用。由于卡存储容量及数据安全的原因，在卡中不会写过多的信息，主要记录的数据包括：病人ID，姓名等。要实现医院所有部门、科室实现一卡通，特别是门诊部门（因为住院部门的病人各种信息已经能够完整连贯），就要求在软件系统中能够保存、读取更多的数据，而且这些数据必须在病人就医过程中一直保存。 这样的数据就是卡应用的数据基础。 目前，我们可以卡应用的数据基础理解为“病人信息主索引”和MEDICAL_CARD_MEMO。 那么，在卡运作过程当中就要关注该数据信息：什么位置产生病人信息主索引？刷卡时如何调用该信息？数据保存到什么时候？门诊病人信息量大，连贯性不强，该如何处置？这些问题都应当同医院相关部门讨论清楚。
xxxxx系统详细设计说明书
版本历史
修改记录
目录 1引言 (5) 1.1编写目的 (5) 1.2背景 (5) 1.3参考资料 (5) 1.4术语定义及说明 (5) 2设计概述 (5) 2.1任务和目标 (5) 2.1.1需求概述 (5) 2.1.2运行环境概述 (5) 2.1.3条件与限制 (6) 2.1.4详细设计方法和工具 (6) 3系统详细需求分析 (6) 3.1详细需求分析 (6) 3.2详细系统运行环境及限制条件分析接口需求分析 (6) 4总体方案确认 (6) 4.1系统总体结构确认 (6) 4.2系统详细界面划分 (7) 4.2.1应用系统与支撑系统的详细界面划分 (7) 4.2.2系统内部详细界面划分 (7) 5系统详细设计 (7) 5.1系统程序代码架构设计 (7) 5.1.1UI(User Interface)用户界面表示层 (7) 5.1.2BLL(Business Logic Layer)业务逻辑层 (8) 5.1.3DAL(Data Access Layer)数据访问层 (8) 5.1.4Common类库 (8) 5.1.5Entity Class实体类 (8) 5.2系统结构设计及子系统划分 (8) 5.3系统功能模块详细设计 (9) 5.3.1XX子系统 (9) .1XX模块 (9) 列表和分页 (9) 创建XX (9) .2XX模块 (9) XX列表 (9) XX修改 (9) 5.3.2XX子系统 (9) 5.3.6.1用户管理模块 (9) 5.3.6.2角色管理模块 (14) 5.3.6.3系统设置模块 (14) 5.3.6.4系统登录注销模块 (14) 5.4系统界面详细设计 (14) 5.4.1外部界面设计 (14) 5.4.2内部界面设计 (14) 5.4.3用户界面设计 (14) 6数据库系统设计 (14) 6.1设计要求 (14) 6.2信息模型设计 (14) 6.3数据库设计 (14) 6.3.1设计依据 (14)
系统对接设计 1.1.1 3.7.3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、 外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范， 对于W3C UDDI v2 API结构规范，采取UDDI v2 的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于 SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs 实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 3.3.8接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口
XXXXXX XXXXXXXXXXXXX 项目名称 详细设计说明书 XXX公司 二〇XX年X月
文档修改记录
目录 第一章引言............................................. 错误!未定义书签。 目的............................................. 错误!未定义书签。 背景............................................. 错误!未定义书签。 术语定义......................................... 错误!未定义书签。 参考资料......................................... 错误!未定义书签。第二章系统概述......................................... 错误!未定义书签。第三章程序1设计说明................................... 错误!未定义书签。 程序描述......................................... 错误!未定义书签。 模块架构图 ................................... 错误!未定义书签。 功能 ......................................... 错误!未定义书签。 类图 ......................................... 错误!未定义书签。 增加功能（功能点） ........................... 错误!未定义书签。 程序流程 ..................................... 错误!未定义书签。 测试和限制条件 ............................... 错误!未定义书签。 备注 ......................................... 错误!未定义书签。第四章程序2设计说明................................... 错误!未定义书签。第五章公用接口程序说明................................. 错误!未定义书签。 全局变量......................................... 错误!未定义书签。 公用界面或接口................................... 错误!未定义书签。 公用方法和过程................................... 错误!未定义书签。第六章附件............................................. 错误!未定义书签。详细设计评审意见.......................................... 错误!未定义书签。
软件详细设计 引言 引言是对这份软件系统详细设计报告的概览，是为了帮助阅读者了解这份文档如何编写的，并且应该如何阅读、理解和解释这份文档。 编写目的 说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库支持)编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构，从而对该软件产品的物理组成进行准确的描述。 如果这份软件系统详细设计报告只与整个系统的某一部分有关系，那么只定义软件系统详细设计报告中说明的那个部分或子系统。 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种编写约定。编写约定应该包括： ●部件编号方式； ●界面编号方式； ●命名规范： ●等等。
预期读者和阅读建议 列举本软件系统详细设计报告所针对的各种不同的预期读者，例如，可能的读者包括： ●开发人员； ●项目经理； ●测试人员； ●文档编写人员； ●等等。 描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。 参考资料 列举编写软件系统详细设计报告时所用到的参考文献及资料，可能包括： ●本项目的合同书； ●上级机关有关本项目的批文； ●本项目已经批准的计划任务书； ●用户界面风格指导； ●开发本项目时所要用到的标难； ●系统规格需求说明； ●使用实例文档； ●属于本项目的其它己发表文件； ●本软件系统详细设计报告中所引用的文件、资料； ●相关软件系统详细设计报告； ●等等。 为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出： ●标题名称； ●作者或者合同签约者； ●文件编号或者版本号； ●发表日期或者签约日期； ●出版单位或者资料来源。
系统对接设计 1.1.1 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2 的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile ，利用J2EE Session EJBs 实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口
系统对接设计 1.1.1对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2的API的模型，定义UDDI 的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL 认证等方式保证集成互访的合法性与安全性。
数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。 1.1. 2.1接口定义约定 客户端与系统平台以及系统平台间的接口消息协议采用基于HTTP协议的REST风格接口实现，协议栈如图4-2所示。 图表错误!文档中没有指定样式的文字。-接口消息协议栈示意图系统在http协议中传输的应用数据采用具有自解释、自包含特征的JSON 数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。 在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支
欢迎阅读系统对接设计 1.1.1 3.7.3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 3.3.8接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必
须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。 1.1. 2.1接口定义约定 客户端与系统平台以及系统平台间的接口消息协议采用基于HTTP协议的 ?host：应用支撑平台交互通信服务的IP地址或域名 ?port：应用支撑平台交互通信服务的端口 ?app name：应用支撑平台交互通信服务部署的应用名称 ?business component name：业务组件名称 ?action：业务操作请求的接口名称，接口名字可配置
应答的消息体采用JSON数据格式编码，字符编码采用UTF-8。 应答消息根节点为“response”，每个响应包含固定的两个属性节点：“status”和“message”。它们分别表示操作的返回值和返回消息描述，其他的同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。 当客户端支持数据压缩传输时，需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答的数据报文进 接口应提供业务数据检查功能，即对接收的数据进行合法性检查，对非法数据和错误数据则拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系统主机处理负荷。 对于接口，其业务数据检查的主要内容有以下几个方面： ? 数据格式的合法性：如接收到非预期格式的数据。包括接收的数据长度，类型，开始结束标志等。
媒讯集团E A S项目CTC与EAS接口需求及设计说明书 文档作者： 创建日期：2013-05-10 确认日期： 当前版本： 拷贝数量：1 审批签字: 客户方： 实施方：
文档控制
目录 1. 概述错误!未定义书签。 读者错误!未定义书签。 图例错误!未定义书签。 目的错误!未定义书签。 二、业务现状错误!未定义书签。 三、概要设计错误!未定义书签。 接口通讯方式错误!未定义书签。 通讯内容定义错误!未定义书签。 媒讯CTC系统提供接口使用范例错误!未定义书签。 金蝶EAS提供接口使用范例错误!未定义书签。 媒讯CTC系统提供接口服务地址错误!未定义书签。 金蝶EAS提供接口服务地址错误!未定义书签。 接口需求错误!未定义书签。 四、详细设计错误!未定义书签。 EAS接口错误!未定义书签。 概述 金蝶与用户及用户业务系统方通过多次讨论，制定了接口开发需求设计说明书，作为双方后续开发指引。读者 本文读者对象为业务管理人员、系统设计、开发人员、测试人员。
图例 本文中如未进行特殊说明，各图标代表的含义如下： 表示流程走向； 目的 本文档是媒讯CTC系统与EAS系统接口的需求及设计方案相关文档，可用于指导开发、测试工作和作为验收相关依据文档。 二、业务现状 待补充 三、概要设计 接口通讯方式 金蝶EAS与媒讯CTC系统之间通讯采用WebService方式进行数据传输。 通讯内容定义 对于记录型的大对象，在通讯时，采用String型的xml格式的参数进行传递。对于其他非记录型的对象，在通讯时，可采用非xml格式的参数进行传递，也可使用多个参数。具体格式，请参照每个接口的通讯用例说明。 媒讯CTC系统提供接口使用范例 待补充。
版本：V1.00 合成子系统A接口合成模块详细设计 目录 1A接口合成模块功能概述 (3) 2A接口合成模块对外接口描述 (3) 2.1输入接口 (3) 2.1.1信令接收 (3) 2.1.2MAP翻译结果接收 (4) 2.2输出接口 (4) 2.2.1合成流程TDR输出 (4) 2.2.2合成统计类数据输出 (4) 2.2.3合成实时状态 (4) 3A接口合成模块内部模型组织方案 (5) 4模块内主要业务处理 (6) 4.1TMSI翻译 (6) 4.2各类型流程合成 (6) 4.3超时处理 (6) 5合成逻辑建模 (7) 5.1正常流程合成处理 (8) 5.1.1主叫流程 (8) 5.1.2被叫流程 (10) 5.1.3位置更新 (12) 5.1.4短消息类流程 (13) 5.1.5IMSI分离 (17) 5.1.6切换类事件流程 (17) 5.1.7补充业务类 (19) 5.2异常流程合成处理 (22) 5.2.1流程未结束 (22) 5.2.2流程不完整 (23) 5.3Imsi查询 (23) 5.4物理模型调整 (23) 6合成统计 (23) 6.1MSC统计 (23) 6.2LAC统计 (23) 6.3BSC统计 (24) 6.4切换统计 (25) 6.5合成成功率 (25) 6.6线路统计 (25) 6.7CGI统计 (25) 7数据分发 (26) 7.1采集板数据分发处理流程 (27)
7.2切换数据的迁移 (27) 7.3正常位置更新消息协助处理 (27) 8实时跟踪 (27) 8.1跟踪条件管理 (28) 8.2合成跟踪处理 (29) 8.3输出管理 (29) 9数据定义 (30) 9.1输入信令结构定义 (30) 9.2合成TDR/CDR (30) 9.2.1各流程类型公共数据TDR (30) 9.2.2通话流程(主叫被叫)TDR (32) 9.2.3位置更新TDR (33) 9.2.4BSC内部切换流程TDR (33) 9.2.5BSC间切换流程TDR (33) 9.2.6切换要求TDR(通话结束生成) (34) 9.2.7短消息流程TDR (34) 9.2.8补充业务 (36) 9.3信令合成输出表结构参考 (36) 9.3.1结构类型 (36) 9.3.2流程类型 (37) 9.3.3A接口结果字段取值种类 (37) 9.4合成模块统计结果 (38) 9.4.1总体统计 (38) 9.4.2分MSC统计 (38) 9.4.3分BSC统计 (38) 9.4.4分LAC统计 (38) 9.4.5其他 (39) 10线程分解 (39) 10.1信令接收线程 (39) 10.2信令分发线程 (39) 10.3业务处理线程 (39) 10.4结果输出线程 (39) 11数据库设计 (39) 11.1MSC表 (39) 11.2BSC表 (40) 11.3LAC表 (40) 11.4BSC线路表 (41) 11.5MAP统计表 (41) 12界面 (41) 附录 A词汇表 (42) 附录 B待定问题 (44)
课程设计说明书设计名称：计算机操作系统课程设计 题目：操作系统命令接口设计 学生：协鎏 专业：计算机科学与技术 班级： 13计算机科学与技术2班 学号：2013314209 指导教师：任朝晖、曾凡智、黄营、周燕 日期：2015年 9 月 20 日
计算机科学与技术专业 2013 年级 2 班协鎏 一、设计题目 操作系统命令接口设计 二、目的和要求 （1）本设计的目的是通过设计一些简单的操作系统的命令接口，使学生掌握操作系统接口的设计方法。 （2）要求学生在熟悉操作系统的命令接口及程序接口的基础上，利用C语言设计简单的命令接口。命令接口基于DOS的命令行接口。 三、设计容 利用C语言、DOS中断中21H与屏幕显示相关的中断调用完成设计，具体包括： 1.命令解释器 2.列目录命令 3.显示时间命令 4.显示日期命令 5.回显字符串命令 6.创建目录命令 7.删除目录命令 8.更改路径命令 9.显示当前工作目录命令 10.删除文件命令 11.打印文本命令 12.文件重新命名 13.显示文本命令 14.显示版本命令 15.显示目录结构命令 16.清除当前显示容命令 上述容中，所有命令通过命令解释器能够执行，即启动命令解释器以后，输入相应命令，按照输入指令执行相应功能，并在屏幕上显示相应结果。
四、进度安排 依照教学计划，课程设计时间为：2周。 1.要求讲解、资料查找、系统分析，概要设计（2天） 2.系统详细设计、功能设计（2天） 3.算法实现、编程调试（5天） 4.功能演示、资料整理、课程设计说明书编写。（1天） 五、完成后应上交的资料 课程设计的总结报告，主要包括以下容： 1.课程设计的题目、系统的总功能和各子模块的功能； 2.源程序代码； 3.课程设计中遇到的主要问题和解决方法； 4.设计中存在的不足及改进的设想； 5.本次课程设计的感想和心得体会。 六、总评成绩 指导教师签名日期年月日 系主任审核日期年月日