专利名称：Umb区站调制解调器架构和方法
技术领域：
本发明的公开内容主要涉及区站调制解调器，更具体地，涉及使用区站调制解调 器进行定时对准和RF控制。
背景技术：
无线通信系统已经广泛部署以提供各种类型的通信内容，例如，语音、数据等。这 些系统可以是多址系统，其能够通过共享可用系统资源(例如，带宽和发射功率)来支持与 多个用户的通信。这些多址系统的实例包括码分多址(CDMA)系统、时分多址(TDMA)系统、 频分多址(FDMA)系统、3GPP LTE系统以及正交频分多址(OFDMA)系统。通常，无线多址通信系统可以同时支持多个无线终端进行通信。每个终端通过前 向链路和反向链路(又称为返回链路或上行链路)上的传输与一个或者多个基站进行通 信。前向链路(或下行链路)是指从基站到终端的通信链路，而反向链路(又称为返回链 路或上行链路)是指从终端到基站的通信链路。可以通过单输入单输出系统、多输入单输 出系统或多输入多输出(MIMO)系统来建立该通信链路。MIMO系统使用多个(Nt)发射天线和多个(Nk)接收天线进行数据传输。Nt个发射 天线和Nk个接收天线组成的MIMO信道可以分解为Ns个独立信道，其也被称为空间信道，其 *Ns<min{NT，NK}。Ns个独立信道中的每一个对应于一个维度。如果利用多个发射天线 和接收天线创建的额外的维数，则MIMO系统能够提供更好的性能(例如，更高的吞吐量和 /或更高的可靠性)。例如，MIMO系统可以支持时分双工(TDD)系统和频分双工(FDD)系 统。在TDD系统中，前向链路传输和反向链路传输在相同的频率区域上，使得互易原理允许 从反向链路信道估算前向链路信道。这就使得当接入点存在多个天线时，接入点可以在前 向链路上提取出发射波束成形增益。当今的宽带无线系统要求效率高、功能强的硬件，例如，专用集成电路(ASIC)，来 支持高速率的数据通信，并且也要求高度灵活的装置来支持多变的控制信道。数据信道通 常使用标准调制技术，如四相相移键控(QPSK)、正交幅度调制(QAM)等。然而，控制信道(包 括不同的导频信道)需要特别处理。控制信道本质上只有较低的吞吐量，但却要求高可靠 性。因此，控制信道通常采用特殊的调制方案，不规则且变化的音调/正交频分复用(OFDM) 符号资源分配，信道特定的跳变，以及在不同信道中重用音调资源。并且，作为无线标准演 进的一部分，控制信道也在随着时间改变。不同的标准(例如超移动宽带(UMB)和长期演进 (LTE))中的控制信道格式在系统中也有很大的区别且具有灵活性，以便适应多功能性的这 种或那种需要。
发明内容
本发明公开了用于定时对准和/或RF控制的装置和方法。根据一个方面，用于采 样同步的方法包括从射频前端(RFFE)接收返回链路(RL)时间戳；从导航和定时系统接 收系统时间秒；基于RL时间戳和系统时间秒生成前向链路(FL)时间戳；并将FL时间戳和 系统时间秒包括到时间数据中。根据另一个方面，用于RF控制的方法，包括在存储器中存储增益信息和选通 控制信息；以及执行以下一个或多个步骤发送第一期望时间戳和增益信息到射频前端 (RFFE)；发送第二期望时间戳和txEnable命令到发送选通控制；或者发送第三期望时间戳 和rxEnable命令到接收选通控制。根据另一个方面，用于采样同步的区站调制解调器(CSM)包括如下配置的处理器 和电路从射频前端(RFFE)接收返回链路(RL)时间戳；从导航和定时系统接收系统时间 秒；基于RL时间戳和系统时间秒生成前向链路(FL)时间戳；以及将FL时间戳和系统时间 秒包括到时间数据中。根据另一个方面，用于RF控制的区站调制解调器(CSM)包括如下配置的处理器和 电路在存储器中存储增益信息和选通控制信息；以及执行以下一个或多个步骤发送第 一期望时间戳和增益信息到射频前端(RFFE)；发送第二期望时间戳和txEnable命令到发 送选通控制；或者发送第三期望时间戳和rxEnable命令到接收选通控制。根据另一个方面，用于采样同步的设备包括用于从射频前端(RFFE)接收返回链 路(RL)时间戳的模块；用于从导航和定时系统接收系统时间秒的模块；用于基于RL时间 戳和系统时间秒生成前向链路(FL)时间戳的模块；以及用于将FL时间戳和系统时间秒包 括到时间数据中的模块。根据另一个方面，用于RF控制的设备，包括用于在存储器中存储增益信息和选 通控制信息的模块；以及用于执行以下一个或多个步骤的模块发送第一期望时间戳和增 益信息到射频前端(RFFE)；发送第二期望时间戳和txEnable命令到发送选通控制；或者发 送第三期望时间戳和rxEnable命令到接收选通控制。根据另一个方面，计算机可读介质包括存储于其上的程序代码，所述计算机可读 介质包括用于从射频前端(RFFE)接收返回链路(RL)时间戳的程序代码；用于从导航 和定时系统接收系统时间秒的程序代码；用于基于RL时间戳和系统时间秒生成前向链路 (FL)时间戳的程序代码；以及用于将FL时间戳和系统时间秒包括到时间数据中的程序代码。根据另一个方面，计算机可读介质包括存储于其上的程序代码，所述计算机可读 介质包括用于在存储器中存储增益信息和选通控制信息的程序代码；以及用于执行以下 一个或多个步骤的程序代码发送第一期望时间戳和增益信息到射频前端(RFFE)；发送第 二期望时间戳和txEnable命令到发送选通控制；或者发送第三期望时间戳和rxEnable命 令到接收选通控制。本发明的优势包括使用通用串行接口对准前向链接和反向链接(通常称为返回 链接)之间的定时参考的能力，以及使用同一通用串行接口提供RF控制功能的能力。需要理解的是，对于本领域技术人员来说，根据以下详细描述，本发明的其他方面将是显而易见的，其中以举例说明的方式示出并且描述了各个方面。附图和详细描述应当 认为是示例性的而不是限定性的。
图1示出了多址无线通信系统的实例的框图；图2示出了无线MIMO通信系统的实例的框图；图3示出了有数个接口的区站调制解调器(CSM)的逻辑架构的实例；图4示出了用于所有CSM的一个管理主机的实例；图5示出了第一阶段超移动宽带(UMB)接入点(AP)参考设计架构的实例；图6示出了第二阶段UMB AP参考设计架构的实例；图7示出了在前向链路(FL)和返回链路(RL)上处理数据信道MAC分组所涉及的 关键元件的实例；图8示出了 CSM消息头部的实例；图9示出了业务信道分配消息流的实例；图10示出了前向链路(FL)数据流和加密掩码生成的实例；图11示出了返回链路(RL)数据流和解密的实例；图12示出了接入点的示例性框图；图13示出了 FL和RL采样接口的示例性表示；图14示出了用于采样同步的示例性流程图；图15示出了适用于采样同步的设备的实例；图16示出了用于RF控制的示例性流程图；图17示出了适用于RF控制的设备的实例；图18示出了包括与存储器进行通信的处理器的设备的实例，以用于采样同步和/ 或RF控制。
具体实施例方式在下文中展示的详细说明结合附图将试图作为若干个方面对本发明的说明，但并 不代表本发明在部署实施时局限于这些方面。本公开中描述的每一个方面，仅仅是作为本 公开的实例或举例说明被提供，不应当被认为比其他方面优选或者更有利。下文中的详细 描述包含了用于提供对本公开的完整深入理解的特定细节。但是，对本领域的技术人员而 言显而易见的是，即使没有这些特定细节，也能对本公开进行实施。在一些实例中，众所周 知的结构和设备以框图的形式被给出，以避免和本公开的概念相混淆。仅仅是出于方便和 简洁的原因，可以使用缩略语和其他描述性的术语，但这不意味着限制本公开的保护范围。同时，出于简化解释的目的，方法被表示和描述为一系列的动作，应当理解并意识 到，这些动作并没有先后顺序的限制，根据一个或多个方面，某些动作可能以不同顺序发 生，和/或与本文表示和描述的其他动作同时发生。例如，本领域的技术人员能够理解并意 识到，方法可能可替换地被描述为一系列相互关联的状态或事件，比如在状态图中。并且， 并不是需要所有示出的动作来实现根据一个或多个方面的方法。下文中描述的技术可以用于各种不同的无线通信系统，例如码分多址(CDMA)系统、时分多址(TDMA)系统、频分多址(FDMA)系统、正交FDMA (OFDMA)系统、单载波 FDMA(SC-FDMA)系统等。术语〃系统〃和〃网络〃经常可交换使用。CDMA系统可以实现 无线技术，比如通用陆地无线接入(UTRA)、cdma2000等。UTRA包括宽带-CDMA (W-CDMA)和 低码片速率(LCR)。Cdma2000包括IS-2000、IS-95和IS-856标准。TDMA系统可以实现 诸如全球移动通信系统(GSM)等无线技术。OFDMA系统可以实现诸如演进UTRA(E-UTRA)、 IEEE 802. 11、IEEE 802. 16、IEEE 802. 20、Flash-OFDM 等无线技术。UTRA, E-UTRA 禾口 GSM是通用移动通信系统(UTMS)的一部分。长期演化(LTE)是即将推出的使用E-UTRA 的UTMS的一个版本。UTRA、E-UTRA, GSM、UMTS和LTE的描述见于被称为〃第三代合作伙 伴计划"(3GPP)的组织的文档中。Cdma2000的描述见于被称为"第三代合作伙伴计划 2" (3GPP2)的组织的文档中。这些各种无线技术和标准是现有技术。此外，单载波频分多址(SC-FDMA)是另外一种无线通信技术，它利用单载波调制 和频域均衡。SC-FDMA系统和OFDMA系统具有相似的性能和相同的总体复杂度。由于其固 有的单载波结构，SC-FDMA信号具有更低的峰均功率比(PAPR)。SC-FDMA已引起广泛的注 意，尤其是在上行链路通信中，其中就发射功率效率而言，较低的PAI^R极大地有益于移动 终端。在3GPP长期演进(LTE)或演进UTRA中，对于上行链路多址方案，使用SC-FDMA技术 在当前是一种可行的假设。所有上述无线通信技术和标准都可以和本发明中描述的数据中 心式复用算法一起使用。图1的框图示出了多址无线通信系统的例子。如图1所示，接入点IOO(AP)包括 多组天线，一组包括天线104和106，另一组包括天线108和110，还有一组包括天线112和 114。在图1中，对于每组天线只示出了两个天线，但是，对于每个天线组可以使用更多或者 更少的天线。接入终端Iie(AT)与天线112和天线114进行通信，其中天线112和天线114 通过前向链路120将信息发送到接入终端116，通过反向链接118从接入终端116接收数 据。接入终端122与天线106和天线108进行通信，其中天线106和天线108通过前向链 路126将信息发送到接入终端122，通过反向链接124从接入终端122接收数据。在FDD系 统中，通信链路118、120、124和126可以使用不同频率进行通信。例如，前向链路120可以 使用和反向链路118不同的频率。每组天线和/或其被设计来进行通信的区域通常被称为 接入点的扇区。在一个例子中，接入点100覆盖的区域中，每个天线组被设计为和扇区中的 接入终端进行通信。在前向链路120和126上的通信中，接入点100的发射天线利用波束成形以提高 不同接入终端116和124的前向链路的信噪比。此外，接入点使用波束成形向其覆盖范围 内随机分散的接入终端进行发射，与接入点使用单一的天线向其所有接入终端进行发射相 比，这样对相邻小区中的接入终端造成的干扰更少。接入点可以是固定站。接入点也被称 为接入节点、基站或本领域已知的一些其他类似的术语。接入终端也被称为移动站、用户设 备(UE)、无线通信设备或本领域已知的一些其他类似的术语。图2的框图示出了无线MIMO通信系统的例子。图2显示了 MIMO系统200中的接 入点210和接入终端250。在接入点210，从数据源212提供多个数据流的业务数据给发射 (TX)数据处理器214。在一个例子中，每一个数据流通过各自的发射天线进行发射。TX数 据处理器214基于为该数据流选定的特定编码方案对业务数据进行格式化、编码和交织， 以提供编码的数据。
使用OFDM技术，每个数据流的编码数据可以和导频数据进行多路复用。导频数据 通常是已知的数据模式，以已知的方式被处理，并且可以被接收机系统用于估计信道响应。 然后，基于为数据流选定的特定调制调制方案(比如，BPSK、QSPK、M-PSK或M-QAM)，可以对 每个数据流调制(即，符号映射)复用的导频数据和编码数据，以提供调制符号。每个数据 流的数据率、编码以及调制可以由处理器230执行的指令决定。然后，针对所有数据流的调制符号被提供到TX MIMO处理器220，TXMIMO处理器 220可以进一步处理这些调制符号(例如，用于OFDM)。然后，TX MIMO处理器220提供Nt 个调制符号流到Nt个发射机(TMTR) 222a到222t。在一个例子中，TX MIMO处理器220给 数据流的符号和发射这些符号的天线应用波束成形权重。每个发射机222a到222t接收并 处理各自的符号流，以提供一个或多个模拟信号，并进一步调整(例如，放大、滤波以及上 转换)这些模拟信号，从而提供适合在MIMO信道上传输的调制信号。然后，将来自发射机 222a到222t的Nt个调制信号分别从Nt个天线224a到224t发射。在接入终端250，发射的调制信号被Nk个天线252a到252r接收，被天线252a到 252r接收的每个信号依次提供到各自的接收机(RCVR) 254a到254r。每一个接收机254a 到254ι 调整(例如，滤波、放大以及下转换)各自接收到的信号，数字化调整的信号以提供 采样，并进一步处理这些采样以提供对应的"接收到的"符号流。然后，基于特定的接收机处理技术，RX数据处理器260从Nk接收机254a到254r 接收并处理这些Nk个接收到的符号流，以提供Nt个"检测到的"符号流。接着，RX数据处 理器260解调、去交织并解码每个检测到的符号流，以便从数据流中恢复业务数据。RX数据 处理器260的处理和接入点210处的TXMIMO处理器220和TX数据处理器214的处理是相 反的。处理器270周期性地决定采用哪个预编码矩阵(将在下文中介绍)。处理器270构 造由矩阵索引部分和行列值部分组成的反向链路消息。反向链路消息可能包含各种类型的有关通信链路和/或接收到的数据流的信息。 然后，反向链路消息经TX数据处理器238 (该处理器也从数据源236接收许多数据流的业 务数据)处理、调制器280调制、发射机254a到254r调整，并发射回接入点210。在接入点210，从接入终端250发出的调制信号经天线224a到224t接收、接收机 222a到222t调整、解调器240解调、RX数据处理器242处理，以提取出由接入终端250发送 的反向链路消息。接着，处理器230决定使用哪个预编码矩阵来确定波束成形权重，接着， 处理器230对提取到的消息进行处理。本领域的技术人员应该理解，收发机222a到222t在 前向链路上称为发射机，在反向链路上称为接收机。类似地，本领域的技术人员应该理解， 收发机254a到254r在前向链路上称为接收机，在反向链路上称为发射机。在一个方面，区站调制解调器(CSM)实现接入点210的调制和解调功能。特别地， TX数据处理器214的调制器和接入点210的解调器240可以在整合的CSM中实现。图3示 出了具有数个接口的区站调制解调器(CSM)的逻辑架构。所有流入和流出CSM的信息可以 通过串行高速IO(sRIO)接口进行传送。例如，sRIO接口用于和发送机和接收机的RF部分、 TX数据处理器214和RX数据处理器242中的媒体访问控制(MAC)功能、以及处理器230中 的管理面软件进行通信。MAC功能用于调节公共传输链路的多个用户。通过直接存储器写 操作、sRIO消息以及门铃(doorbell)，信息通过sRIO接口进行交换。在一个方面，门铃是 短8比特或16比特的消息。在一个例子中，MAC和管理主机是逻辑实体，并且可以在同一硬件元件上并置。在一个例子中，管理接口提供CSM启动和配置、自检测、心跳、调试和诊断 记录、统计检索等机制。调试记录是指在运行系统中发生的事件的可操作记录。这些通过 消息进行报告并且包含协议和错误事件。诊断记录被用于诊断或监视系统的性能特性。MAC接口用于在CSM和MAC主机之间交换MAC和PHY信息。在前向链路(FL)中， MAC接口允许MAC主机向CSM指示将要通过空中链路发送的信息比特，例如，用于以下一个 或多个信道· F-SCCH (前向共享控制信道)· F-ACKCH (前向应答信道)· F-SPCH (前向分组开始信道)· F-PQICH (前向导频质量指示符信道)· F-FOSICH (前向快速其他扇区干扰信道)· F-IOTCH(前向对热干扰信道)· F-RABCH (前向反向活动比特信道)· F-DCH(前向数据信道)· F-PBCCH (前向主广播控制信道)· F-SBCCH (前向辅广播控制信道)在反向链路(RL)上，CSM向MAC主机提供通过空中链路接收到的比特，例如，用于 如下的一个或多个信道· R-ODCCH (反向OFDMA专用控制信道)· R-CQICH (反向信道质量指示符信道)· R-REQCH (反向请求信道)· R-MQICH (反向MIMO质量指示符信道)· R-SFCH(反向子带反馈信道)· R-BFCH (反向波束反馈信道)· R-CDCCH (反向CDMA专用控制信道)· R-CQICH (反向信道质量指示符信道)· R-REQCH (反向请求信道)· R-PAHCH(反向功率放大器净空信道)· R-PSDCH (反向功率谱密度信道)· R-DCH(反向数据信道)除了通过信道发送的比特，MAC主机还使用消息接口来控制CSM中的各种算法的 行为，以用于功率控制、定时控制和多天线技术。关于该信息是如何传输的细节，将在下文 的RF控制接口部分描述。CSM射频(RF)接口提供协议以用于在CSM和RF前端之间传送时域同相正交(IQ) 基带采样控制消息。这个协议也提供具有网络定时参考的CSM同步。在一个方面，接入点可以由多个发射/接收天线、CSM、MAC主机和管理主机组成。 在一个例子中，CSM可以支持多达4个发射天线和4个接收天线。CSM需要配置应与其相关 联的天线子集。单个MAC主机可以与多个CSM进行接口，以允许支持特定MAC信道上的多 个扇区载波。CSM配置有相关联的MAC和管理主机。图4示出了一个用于所有CSM的管理主机的例子。在一个例子中，接入点参考设计架构包含CSM。在参考设计中，第二层模块(L2M) 是MAC主机，控制面模块(CPM)是管理主机。图5示出了第一阶段超移动宽带(UMB)接入 点(AP)参考设计架构的例子。在这个例子中，CSM是指3个现场可编程门阵列(FPGA)调 制解调器模块(FMM)，其一起实现第一阶段CSM功能。图6示出了第二阶段UMB AP参考设计架构的例子。蜂窝调制解调器模块(CMM) 现在包含CSM并且参考设计支持3个扇区。在一个方面，CSM实现例如如下的一个或多个 功能 来自编码MAC信道的前向链路(FL)处理以生成基带IQ采样。 来自基带IQ采样的返回链路(又称为反向链路)处理以解码MAC信道。
可以由MAC主机来调节功率控制环靶(loop-target)。·对每个接入终端(AT)估计RL定时校正。 在CSM内终止混合ARQ (H-ARQ-自动重复请求)。 在CSM中实现多天线技术(ΜΙΜΟ-多输入多输出，SDMA-空分多址)，以及QORL-准 正交反向链路)但由MAC主机进行控制。·调试和诊断记录。·通过CSMAPI (应用编程接口)中的get/set命令管理CSM配置。MAC主机软件负责例如以下的一个或多个功能· FL活动队列管理·信令协议分组的签名/鉴权 路径内隧道协议 ·无线链路协议(RLP)-分段和组装·流和路径协议·分组合并(consolidation)协议·加密/解密支持· FL和RL数据信道MAC·开销消息· R-CDCCH (反向CDMA专用控制信道)和R-ODCCH (反向OFDMA专用控制信道)消 息处理·使用CSM提供的定时校正的RL定时控制回路· FL和RL链路适配.FL和RL调度器·寻呼调度·连接控制面·信令协议·调试和诊断记录在一个例子中，由CSM中的硬件加速器完成加密和解密。MAC主机通过sRIO接口 控制引擎。图7示出了在前向链路(FL)和返回链路(RL)(又称为反向链路)上处理数据 信道MAC分组的关键部件。MAC主机以每个流为基础在外部存储器中的队列中存储FL高层数据接收分组。基于FL调度算法，MAC主机通过sRIO接口从流的子集中将选取的分组复 制到CSM分组存储器。MAC主机还指示加密引擎为CSM分组存储器中的分组构造加密屏蔽 位，并将这些屏蔽位存储到CSM分组存储器中。MAC主机调度器确定这些分组中的哪部分需 要在特定的物理层帧中以MAC分组的形式通过空中接口被发送，并发送消息到CSM指示它 如何构造这些MAC分组。CSM引入分组的对应字节，使用加密屏蔽位执行异或操作，并生成 MAC分组，然后，由CSM发送机链的其余部分来处理MAC分组。在RL数据信道上接收MAC分组时，CSM处理MAC分组并将所有的PCP (分组封装 协议)、路径、流和MAC分组中的RLP头部转发到MAC主机。根据消息头部，MAC主机指示加 密引擎对MAC分组中的每个SAR (分段和重组)载荷进行解密，并将结果写入恰当的MAC主 机存储器位置。MAC主机中的RLP处理对来自SAR段的分组进行重组。在一个例子中，CSM API (应用编程接口)包含CSM与MAC主机之间以及与管理主 机之间流过sRIO接口的协议和相关联的消息。以引用方式纳入本文的附录A描述了该API。 通过直接存储器读写操作、sRIO消息和门铃，信息在sRIO接口上进行交换。例如，对于直 接存储器存取，使用了标准的RapidIO输入/输出事务NREAD、WRITE、NWRITE和NWRITE_R。 图8示出了 CSM消息头部的例子。流过CSM API的消息具有图8中示出的CSM消息头部。 表1描述了 CSM消息头部中各个字段的例子。表 1 在一个方面，CSM包含具有例如以下一个或多个功能的管理接口 开机启动 机内测试 心跳-运送系统时间戳和sRIO设备ID的消息，该sRIO设备ID标识出CSM应当 将消息(例如记录)发送到的管理主机。缺少来自CSM的心跳响应可以被用来检测CSM故 障以及启动恢复过程的需要。 配置-包含各种用于配置CSM操作的配置参数，例如，RF前端和MAC主机处理器 的sRIO设备ID、可用的发射/接收天线的数目等。 统计 记录-调试和诊断
在一个方面，CSM包含具有例如以下一个或多个功能的MAC接口 ·前导数据-在超级帧的开始发送· FLCS描述符_前向链路控制段描述符· FL DCH分配和MAC分组描述符
·加密掩码生成_用于加密FL数据·解密请求_用于解密RL数据· FL Ack和RL分配请求· RL Ack和FL分配请求.R-DCH MAC 头部.R-DCH 分配· R-CDCCH-RL CDMA控制信道MAC消息和定时信息· R-ODCCH-RL OFDMA 控制信道 MAC 消息· AT管理-从CSM中添加和删除移动台图9示出了业务信道消息流的例子。图10示出了前向链路(FL)数据流和加密掩 码生成的例子。图11示出了返回(又称为反向)链路(RL)数据流和解密的例子。在一个方面，CSM采样接口提供用于在CSM和射频前端(RFFE)之间运送时域IQ 基带采样的协议。该协议还采用网络定时参考和稳健的差错/丢失检测来提供CSM同步。 RFFE通过全球定位卫星(GPS)或一些其他机制来维护系统的全局同步，或者，系统可以采 用局限于单个基站的系统时间工作于异步模式。对于UMB同步操作，例如，空中链路帧结构 是普遍对准的并且回到GPS时间的开始进行参考。RFFE必须向CSM提供系统时间参考，使 得CSM可以采用正确的同步来生成底层帧结构。该系统时间参考是自上一个系统时间秒以 来的采样计数。采样计数时间戳代表紧接着天线处参考的时间戳的采样的绝对时间。图12示出了接入点的示例性框图。GPS接收机将GPS时间输入到控制卡，控制卡 生成Chipxie时钟和一秒脉冲给RFFE。RFFE使用这些时钟来同步采样时间戳，采样时间戳 通过sRIO接口发送到CSM。在一个例子中，对于USB，根据底层物理层(PHY)结构(循环前 缀(CP)大小和时分双工(TDD)中的保护时间)，其帧结构具有不同的重复速率并在不同尺 度上与秒对准。因此，帧结构对准到秒的周期范围是，例如，从7秒到2219秒。为了免除 RFFE理解PHY参数或GPS时间的细节的需要，RFFE仅需要提供从上次系统时间秒脉冲以后 的采样数目的计数器。通过另一种机制将当前的GPS或系统时间秒提供给CSM，比如来自控 制器的消息传递，其通过CSM应用编程接口(API)进行定义。采用当前系统时间秒和系统 时间秒内的采样计数的信息，CSM可以完整地得到系统的帧同步。为了保持差错稳健性，以固定的时间间隔将采样计数器时间戳复用到去往RFFE 以及来自RFFE的采样流。例如，对于IO-MHz带宽UMB频分双工(FDD)模式，时间戳之间的 采样段大小是1024次采样，对于5-MHz带宽UMB FDD模式，时间戳之间的采样段大小是512 次采样。在一个方面，CSM和RFFE使用串行高速IO(sRIO)接口针对前向和反向链路传递采 样信息。通过RFFE发起的sRIO SffRITE, RFFE向CSM发送反向链路(RL)数据。通过CSM 发起的sRIO SffRITE,CSM向RFFE发送前向链路(FL)数据。在一个例子中，sRIO接口具有 以下的最小性能要求·在接口上使用64比特的数据字。
·每个天线至少2个最大长度的sRIO事务(256字节)背对背以最大线速率 (IOGbps)是被接受的。·在小于2个最大长度sRIO事务所代表的平均时间内，写设备不会向相同地址端 口写入超过3个最大长度sRIO事务。·所有的sRIO事务都是依次交付的。·以恒定的平均速率采用恒定的平均延时加抖动来生成来自RFFE的sRIO事务。 任意sRIO事务上引入的最大端到端抖动小于士64/采样率。FL事务源于RL事 务，并可以在RL事务上再现抖动，因此，对于FL事务抖动容限是双倍的。例如，对于IO-MHz 带宽UMB FDD模式，抖动容限为■ < +6. 50微秒，对于RL数据和时间戳SWRITES ；■< +13. 0微秒，对于FL数据和时间戳SWRITES ；■ IQ数据使用全最大长度(256字节)事务写入，以最大化sRIO性能。在一个方面，CSM和天线之间的FL路径延迟和RL路径延迟被量化。需要该信息来 调整发送到CSM的RL时间戳。该调整允许CSM同步地对准FL数据。在建立该同步之前， 无法传递有意义的FL数据。时间戳值代表天线处的采样时间。RFFE必须通过适当地偏移时间戳来解决天线及 其数字采样之间的任何延迟。CSM支持对FL时间戳进行可编程提前以解决传输延迟、最大 抖动边界和RFFE内的延迟。在一个例子中，该提前小于200微秒。图13示出了 FL和RL采样接口的示例性表示。虽然FL和RL都通过一个sRIO接 口与CSM通信，但出于简单性考虑，它们在图13中被分开示出。图13中的例子示出了从接 收天线通过模数转换器(ADC)到CSM的总系统延迟，CSM通过数模转换器(DAC)到发射天线 的延迟等于75毫秒。在这个例子中，75微秒代表CSM与FL和RL上的天线之间的总延迟， 它被用于对FL数据的提前定时进行编程，从而将其同步到系统时间秒。在一个方面，当CSM从RL接收到时间戳，它在FL上添加针对该时间戳编程的提前 定时。这允许在发射天线上对FL采样进行正确同步。在一个方面，采样流格式具有例如以下一个或多个特征·时间戳计数器与系统时间秒对准，使得将0计数作为一个时间戳值进行发送。 采样流包括时间戳，该时间戳表明紧跟着的采样的系统时间。该时间戳预期为恒 定的频率；因此，时间戳之间的采样数取决于采样速率。例如，对于IOMHz带宽UMB FDD模 式，每1024次采样即写入该时间戳。·对于同步的系统操作，系统时间是GPS时间并与GPS秒对准。 时间戳包括数据流所代表的当前操作模式。这是仅用于一致性检查的静态配置。 将基于时间戳之间的采样计数以及时间戳之间的定时测量来实现差错/丢失检测。在一个方面，表2示出了采样计数时间戳格式。表3示出了 RL的采样数据格式。 表4示出了 FL的采样数据格式。表5示出了寄存器编址。表2 表3 表4 表 5 在一个方面，RF控制接口对于接收机增益以及对于TDD模式的发射和接收选通提 供实时控制。该控制接口被称为实时的，是因为它提供了同步命令和数据的机制。在一个 方面，实时控制接口并非用于静态配置，例如合成器及滤波设置或发射功率控制。在一个方 面，实时接口并非用于告警；告警必须在其他地方进行处理。增益和选通控制都是如表6所 示的通过对存储器地址的SWRITE操作来进行的。表7示出了增益控制流的示例性格式。表6 表7 时间戳字段反映了增益变化生效所期望的时间。在一个例子中，RFFE改变增益 (基于增益信息rxGain)的实际时间在期望时间+/_2微秒内。如果时间戳的最高有效位 (MSB)被设置，则RFFE将尽可能快的实现增益变化。CSM在期望时间的最少100微秒内提 交增益改变。如果增益控制命令在以前的增益控制命令生效之前被提交，RFFE可以忽略以 前的命令。因此，对增益控制命令不需要缓冲机制。在期望的时间，RFFE调整其总接收增 益，使得输入和输出功率满足下式rxGain =四舍五入((Pout-Pin)*2)(1)其中，Pin是在天线端口处RFFE对接收功率的估计(dBm)，Pout由下式给出Pout = IOlog (σ 2)(2)其中，ο2是IQ采样的的平均平方数字值。因此，rxGain表示天线与到CSM的数 字RFFE输出之间的期望增益(以0. 5dB步进)。在一个方面，采用加性高斯白噪声(AWGN) 信号来进行校准(calibration)，AWGN信号的带宽覆盖系统输入带宽。这确保了增益反映 出通带上的平均增益。由于测量输入功率在天线端口进行而不是在RFFE输入处进行，RFFE 必须考虑LNA的所有外部增益和线缆损耗。如果RFFE按多个阶段实施增益，则由RFFE决定增益分解。并且，RFFE可以在内 部实施各种自动增益控制(AGC)。例如，AGC可以操作于滤波之前的某RF增益阶段，以防止 由于信道外干扰造成的过载。但是，在一个方面，如果RFFE在一个阶段改变了增益，它将试 图保持从天线到CSM的总增益恒定。如果RFFE不能维持恒定的增益，它将向CSM报告该状 况以及任何其他相关信息。在一个例子中，对于差错容限，RFFE匹配平均增益是在不同的增益设置之间采用 +/-0.5dB的相对精度。差错容限是指整个通带上的平均增益。该接口并不规定rxGain值 的任何绝对精度。在该接口中也不规定其他参数(例如，标称绝对增益值和有效增益设置 范围)，需要通过某些其他静态配置将这些参数传送给CSM。在另一个方面，Tx和Rx选通命令分别在表8和表9中给出。表8 表9 通过Rx增益控制命令，时间戳字段反映了命令生效的期望时间。在一个例子中， RFFE实施命令的实际时间在期望时间的+/-1微秒内。如果设置了时间戳的最高有效位 (MSB)，RFFE就会尽快实施命令。在一个例子中，CSM在期望时间的最少100微秒(最多10 毫秒)内提交命令。此外，任意两个Rx选通控制命令的时间戳对应于最少100微秒的时间 间隔。因此，由于可以最多提前10毫秒提交命令，RFFE需要缓冲最多100个命令。在Tx选通命令中，txEnable比特的值为〃 1 “表明启用Tx。也就是说，与期望的 时间戳之后的采样相对应的数据从天线发送。相反，txEnable比特的值为"0"表明不发 送采样。如果Tx路径在多个阶段实施，控制这些阶段的顺序和定时将被建立。类似地，在 Rx选通命令中，设置或不设置rxEnable比特将启用或停用Rx路径。如果Rx路径在多个阶 段实施，控制这些阶段的顺序和定时将被建立。发送时间戳和数据分组是独立于是否启用 Tx或Rx数据路径的。图14示出了采样同步过程的示例性流程图。在框1410中，接收来自射频前端 (RFFE)的返回链路(也称为反向链路)(RL)时间戳。在框1420中，接收来自导航和定时系 统的系统时间秒。在一个例子中，导航和定时系统可以是全球导航卫星系统(GNSS)、全球定 位系统(GPS)、俄罗斯GL0NASS(全球导航卫星系统)、欧盟的伽利略定位系统、印度的区域 导航卫星系统(IRNSS)、中国的北斗卫星导航和定位系统等其中之一。虽然图中给出的框 1410中的步骤发生在框1420的步骤之前，本领域的技术人员应该理解，在不影响本公开的 保护范围和精神的情况下，框1410中的步骤和框1420中的步骤在时间顺序上可以相互交 换，或者，可同时发生。框1420之后，在框1430，基于RL时间戳和系统时间秒生成前向链路(FL)时间戳。 在一个方面，基于RL时间戳和系统时间秒来调整FL时间戳。框1430之后，在框1440中，
21将FL时间戳和系统时间秒包括到时间数据中。框1440之后，在框1450中，将时间数据复 用到采样流中。在一个方面，接收RL时间戳和系统时间秒的实体是区站调制解调器(CSM)。 在一个例子中，CSM是图12所示的接入点框图的一部分。图15示出了适合采样同步的设备1500的例子。在一个方面，设备1500由至少一 个处理器实现，处理器包括如本文在框1510、1520、1530、1540和1550所描述的配置为提供 采样同步的不同方面的一个或多个模块。。例如，每个模块包括硬件、固件、软件或其任意组 合。在一个方面，设备1500还可以由与至少一个处理器进行通信的至少一个存储器来实 现。图16示出了 RF控制的示例流程图。在框1610中，接收增益信息和选通控制信息。 在框1620中，将增益信息和选通控制信息存储到存储器。在一个方面，表6中给出的参数 被用于框1620中的步骤。框1620之后，在框1630中，发送第一期望时间戳和增益信息到 射频前端(RFFE)。在一个方面，第一期望时间戳反映了增益变化起作用的期望时间。在一 个例子中，表7中给出的参数被用于框1630中的步骤。在一个方面，RFFE使用增益来调整 其增益设置。框1630之后，在框1640中，发送第二期望时间戳和txEnable命令到发送选通控 制器。第二期望时间戳反映了 txEnable命令生效的期望时间。当被执行时，txEnable命 令启用发送(Tx)路径。在一个例子中，表8中给出的参数被用于框1640中的步骤。在一 个例子中，发送选通控制器是RFFE的部件。框1640之后，在框1650中，发送第三期望时间戳和rxEnable命令到接收选通控 制器。第三期望时间戳反映了 rxEnable命令生效的期望时间。当被执行时，rxEnable命 令启用接收(Rx)路径。在一个例子中，表9中给出的参数被用于框1650中的步骤。在一 个例子中，接收选通控制器是RFFE的部件。在一个方面，执行图16中示例流程图的步骤的实体是区站调制解调器(CSM)。在 一个例子中，CSM是图12示出接入点框图中的一部分。在一个方面，独立地发送第一期望时 间戳、第二期望时间戳、第三期望时间戳中的每一个。此外，本领域的技术人员应当理解，虽 然图16中示例流程图给出的是框1630、框1640和框1650的步骤的顺序流，本领域的技术 人员应当理解，在不影响本发明的保护范围和精神的前提下，不同顺序的序列也是可能的。 类似地，第一期望时间戳、第二期望时间戳、第三期望时间戳中的每一个也可能在没有其他 二者的情况下被发送，不论是否启用发送(tx)路径或接收(rx)路径。图17示出了适合RF控制的设备1700的例子。在一个方面，由至少一个处理器来 实现设备1700，处理器包括配置为提供在此描述的框1710、1720、1730、1740和1750的不同 方面的RF控制的一个或多个模块。例如，每个模块包括硬件、固件、软件或其任意组合。在 一个方面，由与至少一个处理器进行通信的至少一个存储器来实现设备1700。本领域的技术人员应该理解，图14和图16的示例流程图中给出的步骤，在不偏离 本发明的保护范围和精神的前提下，其顺序可以互换。本领域的技术人员应该理解，上述流 程图中给出的步骤不是排他的，在不偏离本发明的保护范围和精神的前提下，可以加入其 他步骤，也可以删除示例流程图中的一个或多个步骤。技术人员应该更进一步意识到，本文中结合本文公开的例子描述的各种说明性的 组件、逻辑块、模块、电路和/或算法步骤，可以实现为电路硬件、固件、计算机软件或其组合。为了清楚地说明硬件、固件和软件的这种互换性，上文中提到的各种说明性的组件、块、 模块、电路和/或算法步骤，一般都是对其功能进行描述的。该功能是否实现为硬件、固件 或软件，依赖于整个系统的特定应用场景和施加到整个系统的设计约束。对每一个特定应 用，熟练的技术人员可以以各种方式实现本文中描述的功能，但是这种实现决策不应当理 解为造成对本公开的保护范围或精神的偏离。例如，对于硬件实现，处理单元可以在一个或多个专用集成电路(ASIC)、数字信号 处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列、处理 器、控制器、微控制器、微处理器、设计为能实现这里描述的功能的其他电子单元，或其组合 中实现。对于软件实现，可以通过执行这里描述的功能的模块(例如，过程、函数等)来实 现。软件代码可以存储在存储器单元并由处理器单元执行。此外，文中提到的各种说明性 的流程图、逻辑块、模块和/或算法步骤可以编码为计算机可读指令，其由本领域已知的任 何计算机可读介质运送或由本领域已知的任何计算机程序产品实现。在一个例子中，本文中提到的各种说明性的组件、流程图、逻辑块、模块、电路和/ 或算法步骤由一个或多个处理器实现或执行。在一个方面，处理器耦合到存储器，存储器存 储将由处理器执行的数据、元数据、程序指令等，以便实现或执行文中提到的各种流程图、 逻辑块和/或模块。图18示出了由处理器1810及与其通信的存储器1820组成的设备1800。 在一个例子中，设备1800用于实现图14说明的算法。在一个例子中，设备1800用于实现 图16说明的算法。在一个方面，存储器1820位于处理器1810内部。在另一个方面，存储 器1820在处理器1810外部。在一个方面，该处理器包括实现或执行本文中提到的各种流 程图、逻辑块和/或模块的电路。前述说明的各个方面提供给任何本领域的技术人员以制造或使用本发明。对本领 域的技术人员，显而易见，可以对这些方面进行各种修改，在不偏离本发明的保护范围和精 神的前提下，这里定义的一般原则可以适用于其他方面。附录 A 目录1.引言............................................................311.1 目的...........................................................311· 2 范围...........................................................311. 3 惯例...........................................................311.4修订历史.......................................................311.5 参考...........................................................311. 6技术支持.......................................................331.7 缩略语.........................................................332.系统架构及概述..................................................34
2. 1架构...........................................................34
2. 1. IUMB网络架构..................................................34
2. 1. 2UMB AP参考设计硬件架构........................................36
2. 1. 2. 1第 1 阶段....................................................36
2. 1. 2. 2 第 2 阶段....................................................36
2. 1.3被许可方提供的功能...........................................37
2. 1. 3. 1回程及回程处理.............................................37
2. 1. 3. 2BHQoS.......................................................37
2. 1. 3. 30AM&P 基础结构..............................................37
2. 1.3.4诊断和调试记录.............................................38
2. 1. 3. 5VLAN 使用...................................................38
2. 1. 3. 6网络时间协议以及GPS时间同步................................38
2. 1. 4UMB参考设计软件架构..........................................38
2. 1.4. 1高通消息传递...............................................39
2. 1.4. 2UMB协议栈软件架构..........................................49
2. 1. 4. 3信令流中的协议标记.........................................52
2. 1. 4. 40AM&P 架构..................................................53
2. 1. 4. 5UMB L3M 软件架构.............................................62
2. 1. 4. 6 启动.......................................................67
2. 2系统接口.......................................................69
2. 2. 1空中接口.....................................................69
2. 2. 1. IUMB L2M 软件架构.............................................69
2. 2. 2被许可方接口.................................................72
2. 2. 2. IUMB API.....................................................72
2.2. 2. 2CSM API.....................................................72
3.UMB API..........................................................72
3. 1概述...........................................................72
3. 2管理面.........................................................73
3. 2. IUMB消息路由..................................................73
3. 2. 2 控制.........................................................73
3. 2. 3镜像下载.....................................................73
3. 2. 4配置和统计...................................................73
3. 2. 4. 1硬件/软件组件配置..........................................73
3. 2. 5 记录.........................................................73
3. 2. 5. 1调试记录...................................................73
3. 2. 5. 2诊断记录...................................................73
3. 2. 5. 3外部记录...................................................73
3. 2. 6 故障.........................................................73
25
3. 3 数据面.........................................................743. 3. 1 分组流程.....................................................743. 3. 1. IFL 分组处理.................................................743. 3. 1. 2RL 分组处理.................................................743. 3. 1. 3用于切换的RLP分组转发......................................753. 3. 2 配置.........................................................753.3.2.1L3M 功能....................................................753.3.2.2L2M 功能....................................................753. 3. 2. 3FMM/CMM 功能................................................753. 4 控制面.........................................................763.4.1不透明UMB协议消息............................................763. 4. 2AT 管理.......................................................763. 4. 3AT 隧道管理...................................................763. 4. 4空中链路QoS管理..............................................763. 4. 5 记账管理.....................................................763. 4. 6RLP认证/加密密钥管理.........................................763. 4. 7 第二层 AT 管理.................................................764.操作............................................................764. 1 概述...........................................................764. 2 管理...........................................................774. 2.1启动和初始化.................................................774. 2. 2配置和统计获取...............................................784. 3 数据面.........................................................784. 3. IFL 分组处理...................................................784. 3. 1. IDAP 与 FLSS 在相同位置........................................784. 3. 1. 2DAP 与 FLSS 在不同 AP 上.......................................784. 3. 2RL 分组处理...................................................79 4. 3. 2. IRLSS 使用 DAP 向 AGW 发送......................................794. 3. 2. 2RLSS 直接向 AGW 发送..........................................794. 4 控制面.........................................................794. 4.1 上电.........................................................794. 4. 1. 1 使用 EAP 认证上电............................................794. 4. 1. 2 使用 MIP_FAv4 上电...........................................824. 4. 2 切换.........................................................834. 4. 2. 1相同AGW服务的AP之间的切换.................................834. 4. 2. 2不同AGW服务的AP之间的切换.................................874. 4. 3 睡眠.........................................................884. 4. 3. 1清除连接关闭...............................................884. 4. 3. 2 连接丢失...................................................89
4. 4. 4 位置跟踪.....................................................904. 4. 4. 1成功的位置跟踪更新.........................................904. 4. 4. 2失败的位置跟踪更新.........................................904. 4. 5 寻呼.........................................................904. 4. 5. 1本地寻呼唤醒...............................................904. 4. 5. 2远程寻呼唤醒...............................................914. 4. 5. 3 失败的寻呼.................................................914. 4. 6 动态 QoS......................................................924. 4. 6. 1 成功的 QoS 协商..............................................924. 4. 6. 2 失败的 QoS 协商..............................................92图目录图2-1UMB架构参考模型..............................................34图2-2UMB逻辑网络架构..............................................35图2-3示出了第1阶段UMB AP参考设计架构............................36图2-3第1阶段UMB AP参考设计架构图................................36图2-4示出了第2阶段UMB AP参考设计架构............................36图2-4第2阶段UMB AP参考设计架构图................................36图2-5UMB协议分布..................................................39图2-6UNIX消息传递架构.............................................41图2-7基于RTOS的消息传递架构......................................42图 2-8DB GET 消息流.................................................54图 2_9TYPE_DB_GETKEYS 消息流........................................55图 2_10TYPE_DB_N0TIFY 消息流........................................56图 2-11DB_REGISTER 消息流...........................................57图 2_12DB_SET 消息流................................................58图2-13批量数据获取消息流..........................................60图2-14诊断和调试记录架构..........................................61图2-15L3M高层软件架构.............................................63图2-16L3M/L2M启动消息流-第一部分.................................68图2-17L3M/L2M启动消息流-第二部分.................................69图 2-18L2M FL 架构..................................................70图 2-19L2M RL 架构..................................................70图3-1数据分组头部.................................................74图4-1启动和初始化——第一部分.....................................77图4-2启动和初始化——第二部分.....................................78图4-3上电-第一页.................................................79图4-4上电-第二页.................................................80图4-5上电-第三页.................................................81图4-6上电-第四页.................................................82
图 4-7L2+L3 切换-新 BSE-第一页.....................................83图 4-8L2+L3 切换-新 BSE-第二页.....................................84图 4-9L2+L3 切换-新 BSE-第三页.....................................85图 4-10L2+L3 切换-原 BSE-第一页....................................86图 4-11L2+L3 切换-原 BSE-第二页....................................87图4-12睡眠-优雅关闭..............................................88图4-13睡眠-连接丢失..............................................89图4-14位置跟踪....................................................90图4-15远程寻呼唤醒................................................91图 4-16QMP 协商的 QoS................................................92表目录表1. 1修订历史.....................................................31表1. 2参考文档和标准...............................................31表2. IUMB架构参考模型功能单元......................................34表2.2QMessage通用头部字段.........................................43表2. 3QMessage心跳消息字段.........................................45表2. 4以太网MAC-48布局字段........................................48表2. 5TTLV 布局字段.................................................49表2. 6协议缩写.....................................................52表2. 7SNP协议类型、协议号和应用程序端口.............................52表2. 8工作组编号方案...............................................661.引言1.1 目的本文描述高通公司 和其他公司在3GPP2主持下设计的UMB API架构。本文描述 UMBAPI的所有方面以及硬件和软件架构，包括调用流程。1. 2 范围本文的撰写是为了被许可方理解怎样使用UMB API构建商用AP系统。假设读者 熟悉OFDM技术、CDMA技术以及已被3GPP2标准化的UMB协议。本文档覆盖高通公司提供 的参考设计的硬件/软件架构以及消息流图和消息定义。1. 3 惯例函数声明、函数名、类型声明和代码示例以不同的字体给出，例如， include.1. 4修订历史本文档的修订历史如表1. 1所示。表1. 1修订历史
版本日期说明A2007年4月初始版本 1. 5 参考
28
参考文档，可能包括高通、标准和资源文档，在表1. 2中给出。不再适用的参考文 档从该表中删除；因此，参考编号可能不是按顺序的。表1. 2参考文档和标准 1. 6技术支持若需要帮助或澄清本文中的信息，请通过如下链接提交服务请求到高通CMDA技 术http//support, cdmatecch. com若不能 Web 访问互联网，也可发送 email 至l| support, cdmatechigualcomm. com.1. 7缩略语术语及缩略语的定义，参考[Ql].2.系统架构及概述2. 1 架构本章提供总体UMB网络和UMB接入点(AP)的系统架构概述。2. 1. IUMB 网络架构图2-1示出了 UMB网络的架构参考模型。该参考模型包括接入终端(AT)和接入 网(AN)之间的空中接口。
图2-1U MB架构参考模型
表2. 1说明了在图2-1中给出的架构参考模型的功能单元。表2. IUMB架构参考模型功能单元 图2-2示出了 UMB系统中各种元件和核心网元件之间的关系< 图2-2UMB逻辑网络架构2. 1. 2UMB AP参考设计硬件架构2. 1. 2. 1 第 1 阶段图2-3示出了第1阶段UMBAP参考设计架构
图2-3第1阶段UMBAP参考设计架构图2. 1. 2. 2第2阶段图2-4示出了第2阶段UMB AP参考设计架构 图2-4第2阶段UMBAP参考设计架构图2. 1. 3被许可方提供的功能被许可方提供的功能是指为了构建可用系统，被许可方AP软件必须提供的所有 功能。这里假设，参考系统和平台中运行的CPM以及UMB协议栈软件一同被交付，被许可方 必须在最终系统中提供这一软件。本节假设被许可方仅使用L3M/L2M/FMM/CMM模块。2. 1. 3. 1回程及回程处理这里假设被许可方需要提供以下功能 到核心网的回程接口 任何需要的防火墙 被许可方特有的网络/端口地址转换 具有以下功能的IP中转■中转所有非隧道流量到CPM IP栈
■在单一 L3M系统中，中转所有的GRE和/或L2TPv3流量到L3M的吉比特 (gigabit)以太网接口。■在多L3M系统中，使用非基于IP的中转表来决定对某个特定的数据应该定向到 哪个L3M2. 1. 3. 2BHQoS在回程聚合能力小于空中接口 RL可能的速率时，在回程接口上使用QoS方法可能 是必要的。L3M将被限制到每个AT、每个流的RL策略，并对流进行DSCP标记处理，在L3M 和被许可方提供的以太网之间离开RL。但是，即使采用RL策略，也可能出现所有AT上的聚 合速率超过回程接口能力的情况，因此，回程服务质量(BHQoS)是必要的。如果回程接口相 对于AN的最大RL速率来说过大，那么不要求使用BHQoS。2. 1. 3. 30AM&P 基础结构假设，当UMB AP参考设计被集成到被许可方的平台上时，被许可方会处理整个操 作管理维护和配置(0ΑΜ&Ρ)子系统。这包括以下功能 管理客户端，例如，CLI和SNMP，以及中间件 对 GET/SET 等命令适配 UMB API 到 / 从 FMM/CMM，L2M 以及 L3M 数据库持久存储 系统开机和初始化· CPM, L2M 和 L3M 的 OS 集成 系统互联拓扑(SRI0，以太网)· AMCIPMI 接 口 镜像服务器(用于下载代码到FMM/CMM，L2M和L3M的示例程序) 消息传递IPC2. 1.3.4诊断和调试记录假设被许可方会从UMB模块提供接收调试/诊断记录流的方法，并将其聚合到系 统之外。这两种流内运行的协议仍在制定中。2. 1. 3. 5VLAN 使用UMB参考设计软件要求使用802. 3pq的以下功能· VLAN 4080将用于L3M和被许可方以太网之间的所有控制流量· VLAN 4081将用于L3M和被许可方以太网之间的所有IP流量· VLAN 4082将用于L3M和L2M之间的所有流量·以下优先级将会被使用 优先级0-尽力交付，系统记录 优先级3-信令 优先级7-心跳2. 1. 3. 6网络时间协议以及GPS时间同步UMB参考设计软件假设，被许可方AP能够终止和潜在地分发NTP时间到UMB软件 组件中。这使得所有的网络协议调试使用相同的参考时钟。此外还假设GPS时间同步能被 分发到FMM/CMM模块。2. 1. 4UMB参考设计软件架构
UMB设计包括许多空中接口协议和许多IP层协议。这些协议分布在不同的模块 中，如图2-5所示。 图2-5UMB协议分布2. 1.4. 1高通消息传递2. 1.4. 1. 1 软件背板为了能在分布式系统中正常工作，软件必须能够准确无缝地和系统中的其他模块通信，不论其在系统拓扑中的位置。此外，所有软件组件能够逻辑地可寻址，以便软件拓扑 的改变能最小化或被消除。这一能力使得能够隐藏分布式系统的拓扑，也能实现软件模块 之间的故障转移。为了实现这些能力，高通已开发出可部署分布式系统的软件背板。这个 背板将被用于构建UMB/CSM API。2. 1.4. 1.2软件背板需求软件背板必须满足以下需求 位置透明性_软件组件不必知道另一个软件组件的物理位置就能通信。 名字解析_消息传递系统应该提供模块将逻辑名称解析为物理地址。 多播-消息传递系统能够提供模块来将消息多播到多个接收者。发送方不必知 道接收者是谁。多播消息应该能够被确认或非确认。已确认的多播消息应当生成单个确认消息给发送方。 协议消息_消息传递系统应该提供模块在任意两个软件组件之间直接发送消 息。这些消息应该能够被确认或者非确认。 别名-消息传递系统应该允许单个组件为其逻辑名称注册一组别名，其都映射 到其真实名称。2. 1.4. 1.3消息传递架构消息传递软件架构将由消息传递服务器(主机)和一组相关联的消息传递实例 (客户端)组成。除了通常的消息传递实例功能，消息传递服务器的特殊之处在于其执行以 下功能 发送HB广播 识别并允许新的消息传递客户端进入系统 管理逻辑名称和多播注册表的主复制 发出多播以保持客户端/从属消息传递实例同步通过以下方式修改主机中的表本地接口操作、ioctl、经由消息队列命令以及来 自客户端/从属实例的远程请求。当逻辑名称解析到已知的软件组件时，每个消息传递实例完全能够本地地或远程 地传递消息，而不需要联系服务器。发送到未知逻辑名称的消息将会失败，不能被正确地发 送。在这种情况下的错误恢复已超出消息传递系统的范畴。每个消息传递实例具有提供消息组件注册到系统中，并接收系统中的任意多播事 件的能力。当多播注册/解除注册发生时，都会通过广播消息通知每个消息传递实例。这 种更新消息传递数据结构使得如果接收到多播事件，消息传递实例知道怎样在系统内广播 该消息。图2-6示出了 UNIX@消息传递架构 图2-6UNIX消息传递架构图2-7示出了基于RTOS的消息传递架构
图2-7基于RTOS的消息传递架构
2. 1. 4. 1. 4QMessage 通用头部
所有在组件间交互的消息使用以下的通用头部 表2. 2描述QMessage通用头部字段表2. 2QMessage通用头部字段 2. 1.4. 1.5 拓扑发现消息传递系统由服务器和一组潜在的关联消息传递实例构成。为了系统能有效的 操作，需要消息传递服务器能发现其他消息传递实例的模块。这可以由消息传递服务器在 初始化完成之后，每一秒发送心跳消息来实现。通过VLAN4080上的广播MAC地址发送心跳。所有已注册的消息传递实例必须响 应该消息。任何新的消息传递实例可以使用此消息来学习应向谁发回响应。从不发送心跳 响应到广播地址，并且必须包含唯一的单播以太网MAC地址。这个新的MAC地址会被服务 器学习到，可以使用SRC MAC地址跟踪该消息传递实例消耗的所有资源。连续3个请求的 心跳消息响应失败，会导致服务器删除该消息传递实例，其所有资源被释放，并发送多播消 息以通知系统中的其余部分。一旦新的实例响应心跳，它还发送消息以获取完整的逻辑名字缓存以及多播注册 表。此外，消息传递代码使用nodelD，即，1字节值，在内部以及内部的“消息传递”所支持的 协议中作为48位以太网地址的替代。显而易见的是，没有两个实例可以有相同的nodelD。 在心跳消息中分发nodelD-以太网映射表。2. 1. 4. 1. 6QMessage 心跳消息心跳消息的特殊在于，它的源和宿都是消息传递子系统。它还是维持消息，因而与 其他消息具有不同的格式，如下所示 表2. 3描述了 QMessage心跳消息字段。表2. 3QMessage心跳消息字段 2. 1. 4. 1. 7 逻辑寻址所有的逻辑地址都应当是基于字符串的名字，类似TCP/IP中的主机名。所有的逻 辑地址都应当以字符串qmsg://开头。消息传递层包括解析这些逻辑名称到物理地址的功 能。这减少了应用程序学习/硬编码系统服务所在的物理MAC地址的需要。所有的基于字符串的名称都解析为以太网硬件地址。注意，这种绑定能够动态的 支持进程重启、获取新的/不同的动态端口，也使得应用程序移去冗余、负载均衡等。每个 逻辑名称必须是对所有的物理地址唯一的。如果服务/应用程序在每个网卡上存在，但是 又必须可唯一寻址的，那么需要在逻辑基本名称后面添加实例号，例如foreignAgent-1， foreignAgent-2等，该实例号与物理地址(例如插槽号)无关。端口号用于在以太网地址外解复用消息到软件组件。换一种说法，以太网地址足 够寻址以交付分组到正确的硬件上。但是，若没有端口号，该分组就可能不能被交付到正确 的软件组件。端口地址被细分为以下范围· 0. . 31消息传递子系统内部使用；对于任何应用程序都不可用· 31.. 253单播动态分配端口· 254无效端口号· 255广播端口号动态端口空间只在给定的消息传递实例上是唯一的。每个消息传递实例必须维护 动态分配端口的表。2. 1. 4. 1. 8位置透明与名字解析2. 1.4. 1.8. 1消息传递资源位置缓存本模块包含了在CPM上的资源位置主机所知的、逻辑名称到物理地址映射的缓 存。它由消息传递kmod通过老化已存在的条目来按需更新。更新基于卡下降、其他刀片上 分配/回收端口以及其他事件。从服务器到客户端的更新通过VLAN4080上的以太网广播 完成。从客户端到服务器的更新通过消息传递模块向资源位置主机发送单播消息完成。2. 1. 4. 1. 8. 2消息传递资源位置服务器该服务器运行在CPM上，为CPM转换逻辑名称到物理名称，还通过VLAN4080上的 以太网广播将当前缓存更新发送到系统中的所有刀片。每个逻辑名称由系统中的任何消息传递实例的客户端来创建。名称服务器缓存的管理基本是通过心跳响应失败自动完成。还存在这样的接口， 它允许清除特定实例的资源。2. 1.4. 1.9 消息类型2. 1. 4. 1. 9. 1 多播消息确认/非确认的多播消息都是接收方不感知的。消息发送方不知道也不关心谁是 该消息的接收方。发送方唯一希望知道的是，系统中已注册的软件组件什么时候处理该消
42息。这是通过单个确认消息实现的，其中该确认消息由消息传递系统在其为确认消息分配 适当的序号后回送至原消息的发送方。这种类型的消息必须总是由客户端注册并由所有的 接收方确认。对接收已注册的多播消息的确认失败会导致FAILURE消息被回送至发送方。2. 1.4. 1.9. 2 协议消息协议消息(也称为点到点消息)是接收方感知的。特别地，发送方必须知道该消 息将要被送到的逻辑地址。消息传递系统同时支持单播和多播协议消息。不像多播消息， 这些协议消息并不注册到消息传递系统中。这种类型的消息将采用不同的通信头部结构， 在该结构中，发送方将包括发送到接收方的逻辑名称和协议消息类型。接收方的消息传递 层将交付该消息到目的端口，并只需知道该消息是否要求回送确认给发送方。这些确认需 要由消息传递层使用cookie进行在途处理，例如跟踪进行中的确认的序列号。2. 1. 4. 1. 10以太网地址分配所有基于以太网的系统都要求每个MAC包含在第二层网络唯一的MAC地址。系统 允许使用从被许可方的IEEE组织唯一标识符(OUI)空间分配的、全局唯一的MAC地址，或 者是生成的仅在系统内唯一的MAC-48地址。这并不适用于作为回程网络一部分的以太网 MAC。那些以太网地址需要是IEEE全局唯一的地址。本节讨论用于创建系统唯一 MAC-48 地址的算法。MAC-48地址算法必须符合以下要求 有办法保证任何被许可方系统内的唯一性，其中提出参考设计模块 支持一个CPU服务于多个以太网MAC的模块 支持具有多个CPU和以太网MAC的模块本参考设计假设被许可方将会从TBD地址提供8位寄存器可读，其提供机架内唯
的地理位置。
Geo. Location1字节系统内唯一的编号；不对该字段的内容做任何假设；由被许可方 来确保该编号在建立的系统内是真正唯一的；否则将会导致消息 传递系统及相关软件模块不能正常工作。Spare8位由发送方设置为0，被接收方忽略2. 1.4. 1. 11通用消息传递类型许多消息都定义为具有固定部分和可变部分。可变部分通常包括称为TTLV的结 构。本节描述TTLV结构。
2. 1.4. 2UMB协议栈软件架构2. 1. 4. 2. IUMB协议栈高层要求CPM UMB协议栈实现为支持以下需要 结构化该软件使得移植到各种CPU和OS易于实现。 允许进行广泛测试，例如，回环、芯片组仿真、移动电话仿真、信令测试等。 如果需要的话，允许被许可方利用我们的基础结构来添加他们的应用程序；如 果被许可方选择不使用我们的基础结构，允许我们的基础结构与他们的基础结构和平共 存。 定义UMB API,以便供应商在没有我们的信令协议栈但是具有我们的CPM协议 栈的子集的情况下能够建立API，以便能和UMB硬件模块(CSM硬件初始化、镜像下载等)对接。2. 1.4. 2. 2UMB 协议栈进程注意，进程是根据部署的OS的不精确的术语。在一些操作系统中，它们可能是真 实的进程，但是在其他操作系统中，它们可能是共享公共内存空间的任务或线程。2. 1. 4. 2. 30AM 进程2. 1. 4. 2. 3. IIxmControl此进程，使用UMB API，用于初始化、心跳和控制L2M/L3M参考设计模块的状态。它 还将Qmessaging路由器表馈送到L3M/L2M。2. 1. 4. 2. 3. 2csmControl此进程，随sRIO驱动，用于初始化、心跳、配置和控制CMM/FMM的状态。CMM/FMM组 件也通过此进程传送调试和诊断记录。2. 1. 4. 2. 3. 3imageServer此进程负责下载镜像到L3M和L2M.2. 1. 4. 2. 3. 4dbServer此进程通过使用XML配置文件并将其内容转换为基于TTLV的消息来将配置推送 到应用程序。2. 1. 4. 2. 3. 51ogServer此进程负责以下功能 将所有的记录配置(级别，每移动设备的过滤器等)馈送给应用程序，使其能进 行实时过滤 从各应用程序提取记录消息，并聚合为记录文件、syslog等。 为调试和诊断记录提供外部接口。2. 1.4. 2. 4UMB协议信令进程2. 1. 4. 2. 4. IActive Set Mgr本进程是协议栈的核心。它服务于以下目的 管理L3M中的移动设备 管理L2M中的第二层ID
· ICI 通知消息的源和宿· EAP 认证器眷终止KEP信令 终止RCP信令2. 1. 4. 2. 4. 2 Neighbor discovery本进程负责维护所有的每个邻居的信息，以及所有邻居发现相关的AT信令。2. 1. 4. 2. 4. 3 pmipClient本进程负责管理与AGW的PMIP接口。2. 1. 4. 2. 4. 4 Qos MgrQos Mgr执行所有从RADIUS配置文件或从AT的QMP信令触发的L2M QoS准入控 制。本进程是随L3M和L2M的数据驱动准入控制信令的完整部分。本进程终止基本的Qos管理协议，并且是计帐的接口。2. 1. 4. 2. 4. 5 Accounting collector本进程管理来自L3M/L2M的收集并且发送记账记录到AGl2. 1. 4. 2. 4. 6 Session Mgr本进程终止来自AT的所有会话层信令，与AT协商特性。2. 1. 4. 2. 4. 7 Page manager本进程负责AT位置跟踪以及AT网络寻呼，当系统工作在分布式S-RNC模式时。2. 1. 4. 2. 4. 8 DNS resolver本进程负责解析并缓存来自DNS服务器的响应。使用DNS响应消息中的TTL来管 理内部缓存。只要积极使用DNS名称，本进程将自动刷新缓存项目。没有被刷新的条目将 最终从缓存中移除。2. 1. 4. 2. 4. 9 Authentication client本进程作为协议栈内其他进程的认证/授权客户端。本客户端与配置好的 RADIUS/Diameter 服务器对接。2. 1. 4. 2. 5 内核模块注意，只有netbsd初始支持内核模块。2. 1. 4. 2. 5. 1 Messaging本内核模块的存在是为了提供基于以太网的通信和多播复制以及响应聚合。此 外，它还负责CSM模块的心跳/发现。2. 1.4.3信令流中的协议标记所有的调用流程图显示了系统中发送的每个消息的协议/消息ID对。表2. 6定 义了缩写到协议名的映射。表2. 6协议缩写 2. 1. 4. 3. IOTA信令分组的动态路由在消息传递系统中，空中(OTA)信令分组必须动态可路由到不同目的端口。驻留 在L2M中的L2路由器，路由信令分组到/从各个CPM应用程序。使用信令网络协议(SNP) 中的协议类型来路由分组。要路由的分组为 通过本地信令流达到的空中链路分组 来自L3M的隧道信令分组为了动态路由分组，CPM将在L2M启动时放入如下表格。注意，该表仅供参考。表2. 7 SNP协议类型、协议号和应用程序端口 2. 1. 4. 4 0ΑΜ&Ρ 架构每个软件组件生成详细信息部分，包括其所有的配置和统计记录。记录可以是单 个的标量字段，或者是多个字段。通过32位记录类型标签以及单一或者复合的键来唯一确 定每个记录实例。 DBM消息由消息头部、DBM头部和载荷组成。以下三个实体是处理UMB参考设计DBM消息的实体 客户端——被许可方的软件，发起命令提供服务或从UMB参考设计进程中获取 数据。客户端的一个例子是CLI或SNMP代理。· dbserver——与客户端以及UMB参考设计进程进行接口的软件。它是参考 软件，可能以其现有的情况被使用，或者被修改后使用、或者被被许可方提供的软件代替。 dbserver进程是本文档中说明的外部接口的使用者。它必须响应来自UMB参考设计进程的 UMB参考设计DBM注册请求。在注册期间，如果对方进行了请求，则它必须将服务提供给对 方。它必须中转从客户端发起的请求到注册为处理该消息的UMB参考设计进程。它必须中 转该消息的响应回发起请求的客户端。它必须实现客户端使用的原始素数据模型和UMB参 考设计进程使用的记录类型数据模型之间的映射。它必须实现客户端使用的DBM消息架构 和在本文中说明的UMB参考设计进程使用的DBM消息架构之间的映射。 应用程序——是UMB参考设计线程/任务/进程。它们向dbserver注册感兴趣 的DBM消息类型，记录类型，以及键名。它们响应自客户端发起的、由dbserver中转的DBM 消息。dbserver进程应当实现为给客户端的请求提供默认值、或者提供已配置的值。 这使得当其在启动时注册其感兴趣的所有DB记录后，所有的软件可以有一致的行为。 dbserver进程将响应默认值或者已保存的配置值。2. 1. 4. 4. 1 软件 API本节说明UMB参考设计DBM API支持的操作。2. 1. 4. 4. 1. 1 TYPE_DB_GETTYPE_DB_GET操作用于从应用程序获取统计信息。请求TYPE_DB_GET请求的组成如下 记录类型 键 零个或多个要获取的数据字段键中不能指定通配符。使用TYPE_DB_GETKEYS消息来解析通配符键。如果获取的记录类型没有对应键名，则指定空键。如果指定0个要获取的数据字段，则返回该记录类型的所有字段，否则，只返回指 定的字段。响应
TYPE_DB_GET响应的组成如下 记录类型 结果——返回0表示成功；所有其他值表示失败。 请求的键 请求的数据字段图 2-8 示出了 TYPE_DB_GET 消息流。 图2-8DB GET 消息流2. 1. 4. 4. 1. 2TYPE_DB_GETKEYSTYPE_DB_GETKEYS操作用于从应用程序获取可以的统计记录的键名。请求TYPE_DB_GETKEYS 请求的组成如下 记录类型响应TYPE_DB_GETKEYS 响应的组成如下 记录类型·结果——返回0表示成功 应用程序知道的键名的列表(仅当成功时)图 2-9 示出了 TYPE_DB_GETKEYS 消息流程。 图 2_9TYPE_DB_GETKEYS 消息流2. 1. 4. 4. 1. 3 TYPE_DB_N0TIFYTYPE_DB_N0TIFY操作用于通知已订阅组件关于记录的变化。请求TYPE_DB_N0TIFY请求的组成如下 记录类型 变化类型(插入、更新或删除) 对应于发生变化的记录的键名 零或多个发生变化的数据字段B 向应TYPE_DB_N0TIFY 消息没有响应。图 2-10 示出了 TYPE_DB_N0TIFY 消息流程。
图 2-10 TYPE_DB_N0TIFY 消息流
2. 1. 4. 4. 1. 4 TYPE_DB_REGISTERTYPE_DB_REGISTER操作用于针对get/set/notify语义注册特定的组件到记录。UMB参考事件进程使用TYPE DB REGISTER消息注册到dbserver进程，以管理感兴 趣的消息类型、记录类型和键名。注册通常发生在进程的初始化阶段。注册由dbserver进 程进行维护。当管理请求到达时，dbserver进程将该消息转换为UMB参考设计管理消息并 将其路由到基于消息类型、记录类型和键名、已注册到该消息的UMB参考设计进程。如果应用程序注册为TYPE_DB_SET消息，在完成该注册之后，dbserver进程将中 转所有已配置的、匹配记录类型和键的记录到该注册的应用程序。将这些作为TYPE_DB_SET 消息发送到应用程序。以这种方式，告知新启动的进程关于其当前配置。请求TYPE_DB_REGISTER 请求的组成如下 感兴趣的记录类型 键名，定义感兴趣的键值。键可能包含通配符，其表明某些或所有字段的所有值 都与该注册相关联。 感兴趣的管理消息类型响应TYPE_DB_REGISTER 响应的组成如下 记录类型 结果——返回0表示成功；所有其他值表示失败。 请求的键 请求的管理消息类型图 2-11 示出了 TYPE_DB_REGISTER 消息流程。
图 2-11DB_REGISTER 消息流
2. 1. 4. 4. 1. 5 TYPE_DB_SET
TYPE_DB_SET消息用于通知UMB参考设计进程关于记录即将改变。请求TYPE_DB_SET请求的组成如下 记录类型 改变的类型(插入、更新或删除) 键，可能是应用程序以前并不知道的一个键。 将要改变的零个或多个数据字段响应TYPE_DB_SET响应的组成如下 记录类型 结果——返回0表示成功；所有其他值表示失败。 改变的类型(插入、更新或删除) 请求的键 请求的数据字段图2-12 示出了 TYPE_DB_SET 消息流程。 图2_12DB_SET 消息流2. 1.4. 4. 2 配置没有任何UMB参考设计进程可以直接访问其配置数据。访问配置数据由dbserver 进程提供。对于UMB参考设计进程运行中的配置，将使用以下的数据路径1.配置改变由客户端发起，并中转到dbserver进程。2. dbserver进程将其转换为关于记录类型和键的TYPE_DB_SET请求，并将其发送 到已注册为接收该记录类型和键的TYPE_DB_SET请求的UMB参考设计进程。3.应用程序接收或拒绝该请求，并将响应发回dbserver进程。
4.如果请求被接收，配置变化由dbserver进程或一些其他被许可方软件添加到 配置数据库。5.对与UMB参考设计进程的初始化，将使用以下数据路径a.作为其初始化的一部分，应用程序发起TYPE_DB_REGISTER请求到dbserver进 程，指示其对某种特定的记录类型和特定的键值(可以是通配符)的TYPE_DB_SET消息感 兴趣。b. dbserver进程将该请求添加到其注册表。c.对于配置数据库中匹配TYPE_DB_REGISTER请求的每个记录和键名，发生以下 情况i. dbserver进程为该记录产生TYPE_DB_SET请求，并将其发送到应用程序。ii.应用程序接收或拒绝该请求，并且将响应发回dbserver进程。以这种方式，UMB参考设计进程的新实例得知其配置。TYPE_DB_GET消息通常定 义为获取记录类型的数据。因此，它可以用于从应用程序获取统计数据或者配置数据或者 这两者，也即，由应用程序维护的任何记录类型。然而，实现可以选择使用TYPE_DB_GET来 仅获取统计数据，并采用不同的数据路径来获取配置数据。例如，响应于客户端的请求， dbserver进程为了获取UMB参考设计配置数据可以直接访问配置数据库，而不是为此询问 UMB参考设计应用程序。2. 1. 4. 4. 3通配符请求除了 TYPE_DB_REGISTER请求，所有包含键的UMB参考设计管理请求都要求该键被 全部指定。换句话说，任何数据获取或修改请求中不允许使用通配符。应用程序中需要使 用通配符的例子是客户端支持tab补齐，并且tab解析为键名。当数据请求中需要通配符 时，应当使用TYPE_DB_GETKEYS请求。2. 1.4. 4. 4批量数据请求当结合TYPE_DB_GET消息使用时，TYPE_DB_GETKEYS消息可以供dbserver进程使 用来解析通配符，并且满足获取批量数据的请求。例如，客户端可以发出用于所有NTP服务 器统计的请求。它向dbserver进程发出该请求。dbserver进程将此请求转换为UMB参考 设计管理接口，其通过首先发出TYPE_DB_GETKEYS请求到已注册为响应记录类型为NTP_ STATS、任意键名的TYPE_DB_GETKEYS请求的UMB参考设计进程。该应用程序用已知键的列 表来响应dbserver进程的请求。dbserver进程接着对该已知键值列表进行迭代，并对每一 个键名发起一个TYPE_DB_GET请求。该应用程序响应匹配该键名的NTP_STATS记录，该响 应由dbserver进程进行聚合，直到得到最终的键值。一旦该情况发生，则将完整的键列表 和数据返回给客户端。图2-13示出了批量数据获取消息流程。 图2-13批量数据获取消息流2. 1. 4. 4. 5诊断和调试记录调试记录是指对运行系统中发生的事件进行可操作的记录。这些包括协议事件和 系统的其他的、本质上非统计的方面。如果这样配置，调试记录自行流出每个模块。将该流 作为TTLV编码流通过q-messaging进行发送。诊断记录允许查看单独用户或一组用户的性能特性。它用于诊断或监控系统的特 定性能特性。通常，诊断记录没有启用。它和调试记录通过不同的流发送，以便能由CPM上 的记录服务器独立地处理。图2-14示出了诊断和调试记录架构。
54
图2-14诊断和调试记录架构2. 1. 4. 4. 5. 1 记录服务器记录服务器提供以下配置数据组 调试记录过滤器——配置记录级别/属性值对 调试记录配单元配置——指示是否对于每个单元记录时间、文件名、函数名和 行号 可读的调试配置——指示是否将可读的调试记录写入Std0Ut、SySl0g或者均不写入。· TTLV文件配置——指示是否启用TTLV文件，如果启用，保存哪个TTLV标记。这 是推动接口。在配置的时间间隔，文件经SCP去往远程机器。· Diameter配置——指示是否启用Diameter协议接口。在启动时，记录服务器注册为通知任何类型的配置数据改变。它验证任何改变并 且回复给dbserver进程。记录服务器处理来自客户端的记录记录，并决定要写入的目的 地。记录服务器可以将调试记录写入以下的宿 文件· qmsg 端 口 调试/诊断记录服务器(流模式)它作为一个Diameter服务器并发送Diameter消息给任何配置的Diameter客户端。2. 1. 4. 5 UMB L3M 软件架构L3M处理IP分组以支持UMB空中链路操作。L3M负责对数据面进行以下操作(在 API的控制下) 针对空中链路QoS支持的IPv4分类· IPv4过滤支持· IPv4分片处理· VOIPRoHC 配置支持 每个移动设备每个流的反向链路策略· IPv6 (以后的工作)L3M通过Cavium Networks 58xx NPU实现。Cavium核心被分为运行于Green Hills SystemsuVelOSity RTOS的单个管理核心和运行Cavium Simple Executive的其余核心。 完全根据Cavium Simple Executive完成IP中转路径。为了简化移植到其他RT0S，管理核 心对于进入RTOS的所有调用使用OS抽象层(OSAL)。使用Cavium Simple Executive的数 据路径核心不需要0SAL，因为Cavium Simple Executive已经是独立于OS无关的。本节覆盖以下控制面主题 启动和镜像下载 配置 统计获取 调试和诊断记录· Sff故障报告· RTOS 抽象层图2-15示出了 L3M高层软件架构
图2-15L3M高层软件架构该软件架构的许多方面依赖于Cavium OCTEON硬件。由于我们处理的是多核设备， 存在许多不同的方式来分配工作。如前文中提到的，L3M的首要目的是针对所有用户业务 执行IP数据路径处理。为实现此目的，大部分的核心(即，除了一个以外)都致力于处理 用户数据分组。这些核心将称为分组处理核心(或者PP核心)。剩余的核心将致力于L3M 的总体管理和控制。该核心将称为管理/控制核心(或者MC核心)。MC核心总是OCTEON 中编号最小的。2. 1. 4. 5. IMC 核心MC核心主要负责与运行在信令处理器上的协议栈软件进行交互和通信。该核心也 负责分配和维护共享内存中的、将会被PP核心访问的所有每用户数据结构。MC核心将运行在Green Hills System uVelOSity RTOS中。MC核心软件被分为 少数的任务/线程。任务的初步列表如下
动
管理/消息传递任务 记录任务 眷命令行接口任务
WD0G/LED 任务 清理任务
IPSEC/MSK 任务
2. 1. 4. 5. 2管理/消息传递任务
管理/消息传递任务负责与运行在CPM上的协议软件的所有通信。其涉及以下活 响应于UMB协议栈发送的命令，添加/删除每AT的数据结构和分类器规则。
收集统计并将其报告回CPM 代理去往/来自上层的分组 添加/删除到L3路由表项目的项 硬件/软件故障报告2. 1. 4. 5. 3 记录任务该任务负责建立并发送调试和诊断记录消息给运行在CPM上的记录服务器应用 程序。该任务还负责接收和处理由PP核心生成的任何内部格式的记录消息。2. 1.4. 5.4命令行接口任务命令行接口对于其运行时监控和调整L3M提供冗余支持。它严格用于开发/调试。2. 1. 4. 5. 5WD0G/LED 任务WD0G/LED任务负责看护核心的硬件看门狗，并且在L3M的LED上显示任何类型的
有用fe息。2. 1. 4. 5. 6移动管理清理任务清理任务负责检查标记为老化的表/项目的状态，但由于该项目可能还在使用而 尚未被删除。2. 1. 4. 5. 7IPSEC/MSK 任务本任务负责MSK键的管理和安全存储，以支持EAP-ER。2. 1.4. 5.8分组处理核心除了最小编号的核心以外的所有核心，都致力于分组处理任务。这些核心将不 会运行完全的RT0S。相反，它们的每一个将使用Cavium Simple Executive。Simple Executive负责硬件初始化并建立C运行环境。每个核心是单线程的，并将运行以下简化代 码片段的实例main (){
} 每个核心将请求来自POW单元的分组进行处理，尽可能快地处理该分组，然后在 需要时释放该分组。如果由于某种原因(例如，该分组是中间的或最后的IP分片，并且第 一个分片还没有接收到)分组处理不能继续进行，那么需要将该分组排队，并且在核心能 够请求新工作以前退出/不调度该工作。
Wrok_t 女 wk ；
while (1)
{
wk = get—work ()；
wk = process_data_pkt(wk)；
if ( wk )
{
Freek work(wk)；
ι
ι
58
2. 1. 4. 5. 9线程间/核心间通信要求在MC核心上的任务之间进行的任何通信将通过高通消息传递API来完成。这 将要求高通消息传递代码移植到UVelOSity上运行。这提供了统一的方法进行任务间通信 以及与运行在CPM上的软件进行通信。PP核心彼此间不需要直接通信，它们也不需要与管理/控制核心上的任何任务明 确通信。需要从PP核心传送到MC核心的任何数据(反之亦然)将通过Cavium处理器中 的POW单元完成。也就是说，任何核心都能够创建新的工作并将其提交到POW进行调度。然 后，基于分组号，POW将该分组引导至合适的核心或核心组进行处理。2. 1. 4. 5. 10共享内存和锁定各种数据结构都需要在共享内存中维护，因为它们可能需要被所有的N个核心访 问。自旋锁用于提供对共享数据结构的排他访问。引用计数也需要被维护以避免MC核心 移除还在被PP核心使用的每用户数据结构。每个每AT数据结构将得到锁的保护。将使用MIPS核心提供的负载连接的并且是存储有条件的指令来实现自旋锁。提 供锁定例程将会聚集统计信息，该统计信息关于该锁被持有的时间以及获取该锁所需要的 时间。添加代码以用于检查死锁条件并且如果发生死锁条件则进行释放。每个核心具有其 自己的硬件看门狗定时器以后，我们也将可以检测这些条件。2. 1.4. 5. 11 工作组编号Cavium POff单元使用分组号来分类并分发工作(即分组)到各核心。有16种可 能的分组号(0-15)。分组号能由PIP/LPD在分组进入系统时通过各种方式进行分配。最 简单的情况是默认的分组号被分配给在特定接口上接收到的所有分组。我们将采用这种方 法。此外，当新的工作核心软件由核心软件创建并提交到POW时，分组号必须明确指明。我 们也将采用该方法。表2. 8示出了当前的分组编号方案。表2. 8工作组编号方案
分组名称说明0控制/管理分配给所有来自控制/管理GigE接口的流量；只有管理/控制核心会 订阅该组1原始IP数据分配给所有来自IP数据GigE接口的流量2已哈希的IP数据分配给分组格式已被识别并生成了哈希的IP流量3L2/L3分配给所有在L2/L3GGigE接口上接收的流量4分组捕获分配给所有由分组处理核心捕获的流量；只有管理/控制核心会订阅 该组5分组注入由管理/控制核心分配给它注入的所有流量；分组处理核心会订阅该 组
59 2. 1.4. 6 启动Cavium SDK包括某版本的开源U-Boot引导加载器软件，其已被修改为可与 OCTEON 工作。2. 1. 4. 6. 1 U-Boot 改动为适合我们的需求，将对U-Boot源代码作了以下两个方面的增强 添加POST和其他诊断代码 添加使用专有协议下载镜像的支持U-Boot当前包含基本的IP支持，能使用TFTP从网络下载代码。由于L3M是集成 到AP中的模块，我们不能依赖于具有可用的IP网络来下载代码。因此，将使用专有的镜像 下载协议来代替。该协议将在以太网上运行，使用高通消息传递。CPM将运行镜像服务器应 用程序，其响应镜像下载请求。精简版的高通消息传递将需要添加到U-Boot中。需要能够使用固定地址来接收 并响应心跳和发送/接收协议消息。不需要参与消息传递系统的名称服务协议。2. 1.4. 6. 2 启动顺序基于以上信息，L3M启动顺序如下从引导Flash引导进入U-Boot。运行POST并保存结果到固定的共享内存块。初 始化设备。引导加载器将在最小编号的核心上运行。其他核心将被复位挂起。在管理/控制接口上侦听高通消息传递心跳请求。CPM会在VLAN4080优先级7上 广播该心跳。一旦发现了镜像服务器的地址，并且VLAN配置已知，引导代码将试图使用镜像传 送协议来下载可工作的镜像(或多个镜像)。注意可能有两个分开的镜像，一个用于控制核心，即基于RTOS的镜像，一个用于分组处理核心。如果可能，它们将被合并为单个核心或打包进单个的包。引导代码然后加载镜像到存储器并使得PP核心离开复位。一旦PP核心运行，弓丨导加载器将需要弓丨导基于RTOS的控制代码，即基本上跳转至IJ 该控制代码。此时，RTOS将初始化其拥有的硬件、初始化存储器，并生成任务。一旦L3M上电并运行，CPM将通过消息交换来配置它。图2-16和图2-17示出了用于使L3M上电离开复位的消息流。 图2-16L3M/L2M启动消息流-第一部分
图2-17L3M/L2M启动消息流-第二部分 2. 2系统接口 2. 2. 1空中接口 2. 2. 1. 1 UMB L2M 软件架构
L2M将重用调试和诊断记录基础结构、0SAL、以及已完成用于L3M的高通消息传递
2. 2. 1. 1. 1L2M FL 架构 图2-18示出了 L2M FL架构。
Ini
62 图 2-18L2M FL 架构2. 2. 1. 1. 2L2M RL 架构图 2-19 示出了 L2M RL 架构。 图 2-19L2MRL 架构2. 2. 1. 1. 3L2M 软件功能L2M为UMB空中链路数据路径实现以下功能· FL活动队列管理 信令协议分组的签名/认证 路径间隧道协议
无线链路协议(RLP)——分片和重组 流和路径协议 分组合并协议 流量信道MAC 加密密钥管理支持 开销消息· R-CDCCH 和 R-0DCCH 消息处理· FL和RL链路适配· FL和RL调度器L2M还为UMB空中链路控制面实现以下功能 寻呼调度 统计收集与获取 连接控制面 信令协议 调试和诊断记录2. 2. 2被许可方接口2. 2. 2. 1 UMB APIUMB API包含物理层、L2和L3模块的数据路径API以及信令路径API。它们共同 提供软件接口，用于发送数据到UMB参考设计和/或接收来自UMB参考设计的数据。2. 2. 2. 2 CSM APICSM API是用于发送数据到UMB调制解调器参考设计中的PHY模块和/或接收 来自UMB调制解调器参考设计中的PHY模块的数据的软件接口，S卩CMM或FMM。L2M使用 CSMAPI 与 CMM/FMM 通信。3. UMB API3. 1 概述UMB API是消息传递API。它可以被视为流过以太网接口的去往L3M、L2M和FMM/ CMM的所有消息的列表。3. 2管理面3. 2. IUMB 消息路由这些消息用于配置FMM/CMM固件、L2M和L3M软件以及协议栈之间的内部消息路3. 2. 2 控制初始化，心跳，控制L3M、L2M，以及FMM/CMM。3. 2. 3镜像下载下载镜像到L3M、L2M 和 FMM/CMM。3. 2. 4配置和统计每个软件组件将提供它要求的DBM记录的列表。3. 2. 4. 1硬件/软件组件配置3. 2. 5 记录 图3-1数据分组头部3. 3. 1. IFL 分组处理这些数据分组(协议)是L3M软件能通过以太网接口接收的分组。3. 3. 1. 2RL 分组处理这些数据分组(协议)是L3M软件能通过以太网接口发送的分组。3. 3. 1. 3用于切换的RLP分组转发这些RLP分组在L2切换时从L2M转发到新的AP。3. 3. 2 配置3.3.2.1L3M 功能3. 3. 2. 1. IQoS分类及防火墙3. 2. 5. 1 调试记录3. 2. 5. 2 诊断记录3. 2. 5. 3 外部记录3. 2. 6 故障每个软件组件将需要详细描述其可能送出的任何故障。3. 3数据面3. 3. 1分组流程IPDataHeaderMessage_c类是所有IP数据消息的基类。L2M和L3M之间发送的每
个数据分组都会附有如图3-1所示的头部。
65
其以每个AT为基础添加和删除防火墙规则和分类器规则。3. 3. 2. 1. 2第三层数据路径管理其打开/关闭TCP MSS调整和ICMP路径MTU发现。3.3.2.2L2M 功能3. 3. 2. 2. IFL 调度器3. 3. 2. 2. 2RL 调度器3. 3. 2. 2. 3 链路适配3. 3. 2. 2. 4 队列管理3. 3. 2. 2. 5RLP3. 3. 2. 3FMM/CMM 功能参考[Q2]3. 4控制面3. 4. 1不透明UMB协议消息这些消息用于发送UMB协议消息到AT。这些消息被第二层软件不透明地对待，即 在RLP中封装并发送。这些协议包括在[S7]中定义的能够在信令网络协议上运输的任何协议。3. 4. 2AT 管理其从第二层和第三层添加和删除AT。3. 4. 3AT 隧道管理其添加和删除用于中转FL流量的AP之间的隧道。3. 4. 4空中链路QoS管理其用于配置L2M和L3M，以同时支持预配置和QMP信号发送的空中链路QoS。3. 4. 5记账管理其允许CMP栈获取对AT会话进行记账必要的FL和RL计数器。3. 4. 6RLP认证/加密密钥管理其给CPM提供了基于EAP-ER或KEP协商结果推送新的RLP会话密钥的能力。3. 4. 7 第二层 AT 管理其为L2M中的AT事件提供了中转到CPM进行处理的能力。4.操作4. 1 概述本章说明针对UMB/CSMAPI捕获使用场景的消息流程图。每节示出了使用UMB/ CSMAPI执行特定功能的不同场景。4. 2 管理4. 2.1启动和初始化图4-1和图4-2示出了启动和初始化流程。 图4-1启动和初始化——第一部分 图4-2启动和初始化——第二部分
4. 2. 2配置和统计获取
4. 3数据面
4. 3. 1FL分组处理
4. 3. 1. 1DAP与FLSS在相同位置
待定
4. 3. 1. 2DAP 与 FLSS 在不同 AP 上
待定
4. 3. 2RL分组处理
4. 3. 2. 1RLSS 使用 DAP 向 AGW 发送
待定
4. 3. 2. 2RLSS直接向AGW发送
待定
4. 4控制面
4. 4. 1上电
4. 4. 1. 1使用EAP认证上电
图4-4上电-第二页 图4-5上电-第三页 图4-7L2+L3 切换-新 BSE-第一页
图 4-8L2+L3 切换-新 BSE-第二页图4-10L2+L3 切换-原 BSE-第一页 图4-12睡眠-优雅关闭4. 4. 3. 2 连接丢失 图4-13睡眠-连接丢失4. 4. 4位置跟踪4. 4. 4. 1成功的位置跟踪更新 [1012] 图 4-16QMP 协商的 QoS4. 4. 6. 2 失败的 QoS 协商待定
权利要求
一种用于采样同步的方法，包括从射频前端(RFFE)接收返回链路(RL)时间戳；从导航和定时系统接收系统时间秒；基于所述RL时间戳和所述系统时间秒生成前向链路(FL)时间戳；以及将所述FL时间戳和所述系统时间秒包括到时间数据中。
2.根据权利要求1所述的方法，还包括将所述时间数据复用到采样流。
3.根据权利要求2所述的方法，还包括发送所述采样流。
4.根据权利要求1所述的方法，其中，所述导航和定时系统是全球导航卫星系统 (GNSS)、俄罗斯GL0NASS(全球导航卫星系统)、欧盟的伽利略定位系统、印度区域导航卫星 系统(IRNSS)或中国的北斗卫星导航和定位系统中的一个。
5.根据权利要求1所述的方法，其中，所述导航和定时系统是全球定位系统(GPS)。
6.根据权利要求5所述的方法，还包括将所述系统时间秒对准到所述全球定位系统 的GPS时间。
7.根据权利要求1所述的方法，还包括将时间戳计数器对准到所述系统时间秒。
8.根据权利要求1所述的方法，其中，对于IOMHz带宽UMB频分双工(FDD)模式，每 1024次采样写入所述FL时间戳。
9.根据权利要求2所述的方法，其中，所述FL时间戳进一步包括所述采样流所代表 的当前操作模式的信息。
10.一种用于RF控制的方法，包括在存储器中存储增益信息和选通控制信息；以及 执行以下步骤之一a)发送第一期望时间戳和所述增益信息到射频前端(RFFE)；b)发送第二期望时间戳和txEnable命令到发送选通控制；或者c)发送第三期望时间戳和rxEnable命令到接收选通控制。
11.根据权利要求10所述的方法，还包括接收所述增益信息和所述选通控制信息。
12.根据权利要求10所述的方法，其中，所述发送选通控制和所述接收选通控制是所 述射频前端(RFFE)的一部分。
13.根据权利要求10所述的方法，还包括执行以下步骤中尚未执行之第二步骤a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
14.根据权利要求13所述的方法，还包括执行以下步骤中尚未执行之最后步骤a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
15.根据权利要求14所述的方法，其中，所述发送选通控制和所述接收选通控制是所 述射频前端(RFFE)的一部分。
16.根据权利要求10所述的方法，其中，所述射频前端(RFFE)的增益的改变发生在基 于所述增益信息的期望时间的+/_2微秒内。
17.根据权利要求16所述的方法，其中，所述期望时间是增益改变生效的时间。
18.根据权利要求10所述的方法，还包括将以下各项中的至少一项复用到采样流第 一期望时间戳、第二期望时间戳、第三期望时间戳、增益信息、txEnable命令或rxEnble命 令。
19.根据权利要求18所述的方法，其中，所述增益信息(rxGain)定义为 rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天线端口处对接收功率的估计，Pout由下式给出 Pout = 101og(o 2)其中，ο 2是所述采样流的平均平方数字值。
20.根据权利要求19所述的方法，其中，所述增益信息(rxGain)代表以0.5dB步进的期望增益。
21.一种用于采样同步的区站调制解调器(CSM)，所述CSM包括如下配置的处理器和电路从射频前端(RFFE)接收返回链路(RL)时间戳； 从导航和定时系统接收系统时间秒；基于所述RL时间戳和所述系统时间秒生成前向链路(FL)时间戳；以及 将所述FL时间戳和所述系统时间秒包括到时间数据中。
22.根据权利要求21所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为将所述时间数据复用到采样流。
23.根据权利要求22所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为发送所述采样流。
24.根据权利要求21所述的区站调制解调器，其中，所述导航和定时系统是全球导航 卫星系统(GNSS)、俄罗斯GL0NASS(全球导航卫星系统)、欧盟的伽利略定位系统、印度区域 导航卫星系统(IRNSS)或中国的北斗卫星导航和定位系统中的一个。
25.根据权利要求21所述的区站调制解调器，其中，所述导航和定时系统是全球定位 系统(GPS)。
26.根据权利要求25所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为将所述系统时间秒对准到所述全球定位系统的GPS时间。
27.根据权利要求21所述的区站调制解调器，所述处理器和所述电路进一步配置为 将时间戳计数器对准到所述系统时间秒。
28.根据权利要求21所述的区站调制解调器，其中，对于IOMHz带宽UMB频分双工 (FDD)模式，每1024次采样写入所述FL时间戳。
29.根据权利要求2所述的区站调制解调器，其中，所述FL时间戳进一步包括所述采 样流所代表的当前操作模式的信息。
30.一种用于RF控制的区站调制解调器(CSM)，其包括如下配置的处理器和电路 在存储器中存储增益信息和选通控制信息；以及执行以下步骤之一a)发送第一期望时间戳和所述增益信息到射频前端(RFFE)；b)发送第二期望时间戳和txEnable命令到发送选通控制；或者c)发送第三期望时间戳和rxEnable命令到接收选通控制。
31.根据权利要求30所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为接收所述增益信息和所述选通控制信息。
32.根据权利要求30所述的区站调制解调器，其中，所述发送选通控制和所述接收选 通控制是所述射频前端(RFFE)的一部分。
33.根据权利要求30所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为执行以下步骤中尚未执行之第二步骤a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
34.根据权利要求33所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为执行以下步骤中尚未执行之最后步骤a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
35.根据权利要求34所述的区站调制解调器，其中，所述发送选通控制和所述接收选 通控制是所述射频前端(RFFE)的一部分。
36.根据权利要求30所述的区站调制解调器，其中，所述射频前端(RFFE)的增益的改 变发生在基于所述增益信息的期望时间的+/_2微秒内。
37.根据权利要求36所述的区站调制解调器，其中，所述期望时间是增益改变生效的 时间。
38.根据权利要求30所述的区站调制解调器，其中，所述处理器和所述电路进一步配 置为将以下各项中的至少一项复用到采样流第一期望时间戳、第二期望时间戳、第三期望 时间戳、增益信息、txEnable命令或rxEnble命令。
39.根据权利要求38所述的区站调制解调器，其中，所述增益信息(rxGain)定义为rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天线端口处对接收功率的估计，Pout由下式给出Pout = 101og(o 2)其中，ο 2是所述采样流的平均平方数字值。
40.根据权利要求39所述的区站调制解调器，其中，所述增益信息(rxGain)代表以 0. 5dB步进的期望增益。
41.一种用于采样同步的设备，包括用于从射频前端(RFFE)接收返回链路(RL)时间戳的模块；用于从导航和定时系统接收系统时间秒的模块；用于基于所述RL时间戳和所述系统时间秒生成前向链路(FL)时间戳的模块；以及用于将所述FL时间戳和所述系统时间秒包括到时间数据中的模块。
42.根据权利要求41所述的设备，还包括用于将所述时间数据复用到采样流的模块。
43.根据权利要求42所述的设备，还包括用于发送所述采样流的模块。
44.根据权利要求41所述的设备，其中，所述导航和定时系统是全球导航卫星系统(GNSS)、俄罗斯GL0NASS (全球导航卫星系统)、欧盟的伽利略定位系统、印度区域导航卫星 系统(IRNSS)或中国的北斗卫星导航和定位系统中的一个。
45.根据权利要求41所述的设备，其中，所述导航和定时系统是全球定位系统(GPS)。
46.根据权利要求45所述的设备，还包括用于将所述系统时间秒对准到所述全球定 位系统的GPS时间的模块。
47.根据权利要求41所述的设备，还包括用于将时间戳计数器对准到所述系统时间 秒的模块。
48.根据权利要求41所述的设备，其中，对于IOMHz带宽UMB频分双工(FDD)模式，每 1024次采样写入所述FL时间戳。
49.根据权利要求42所述的设备，其中，所述FL时间戳进一步包括所述采样流所代 表的当前操作模式的信息。
50.一种用于RF控制的设备，包括用于在存储器中存储增益信息和选通控制信息的模块；以及用于执行以下步骤之一的模块a)发送第一期望时间戳和所述增益信息到射频前端(RFFE)；b)发送第二期望时间戳和txEnable命令到发送选通控制；或者c)发送第三期望时间戳和rxEnable命令到接收选通控制。
51.根据权利要求50所述的设备，还包括用于接收所述增益信息和所述选通控制信 息的模块。
52.根据权利要求50所述的设备，其中，所述发送选通控制和所述接收选通控制是所 述射频前端(RFFE)的一部分。
53.根据权利要求50所述的设备，还包括用于执行以下步骤中尚未执行之第二步骤的 模块a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
54.根据权利要求53所述的设备，还包括用于执行以下步骤中尚未执行之最后步骤的 模块a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
55.根据权利要求54所述的设备，其中，所述发送选通控制和所述接收选通控制是所 述射频前端(RFFE)的一部分。
56.根据权利要求50所述的设备，其中，所述射频前端(RFFE)的增益的改变发生在基 于所述增益信息的期望时间的+/_2微秒内。
57.根据权利要求56所述的设备，其中，所述期望时间是增益改变生效的时间。
58.根据权利要求50所述的设备，还包括用于将以下各项中的至少一项复用到采样流 的模块第一期望时间戳、第二期望时间戳、第三期望时间戳、增益信息、txEnable命令或 rxEnble 命令。
59.根据权利要求58所述的设备，其中，所述增益信息(rxGain)定义为 rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天线端口处对接收功率的估计，Pout由下式给出 Pout = 101og(o 2)其中，ο 2是所述采样流的平均平方数字值。
60.根据权利要求59所述的设备，其中，所述增益信息(rxGain)代表以0.5dB步进的期望增益。
61.一种计算机可读介质，包括存储于其上的程序代码，所述计算机可读介质包括 用于从射频前端(RFFE)接收返回链路(RL)时间戳的程序代码；用于从导航和定时系统接收系统时间秒的程序代码；用于基于所述RL时间戳和所述系统时间秒生成前向链路(FL)时间戳的程序代码；以及用于将所述FL时间戳和所述系统时间秒包括到时间数据中的程序代码。
62.根据权利要求61所述的计算机可读介质，还包括用于将所述时间数据复用到采 样流的程序代码。
63.根据权利要求62所述的计算机可读介质，还包括用于发送所述采样流的程序代码。
64.根据权利要求61所述的计算机可读介质，其中，所述导航和定时系统是全球导航 卫星系统(GNSS)、俄罗斯GL0NASS(全球导航卫星系统)、欧盟的伽利略定位系统、印度区域 导航卫星系统(IRNSS)或中国的北斗卫星导航和定位系统中的一个。
65.根据权利要求61所述的计算机可读介质，其中，所述导航和定时系统是全球定位 系统(GPS)。
66.根据权利要求65所述的计算机可读介质，还包括用于将所述系统时间秒对准到所 述全球定位系统的GPS时间的程序代码。
67.根据权利要求61所述的计算机可读介质，还包括用于将时间戳计数器对准到所述 系统时间秒的程序代码。
68.根据权利要求61所述的计算机可读介质，对于IOMHz带宽UMB频分双工(FDD)模 式，每1024次采样写入所述FL时间戳。
69.根据权利要求62所述的计算机可读介质，其中，所述FL时间戳进一步包括所述 采样流所代表的当前操作模式的信息。
70.一种计算机可读介质，包括存储于其上的程序代码，所述计算机可读介质包括 用于在存储器中存储增益信息和选通控制信息的程序代码；以及用于执行以下步骤之一的程序代码a)发送第一期望时间戳和所述增益信息到射频前端(RFFE)；b)发送第二期望时间戳和txEnable命令到发送选通控制；或者c)发送第三期望时间戳和rxEnable命令到接收选通控制。
71.根据权利要求70所述的计算机可读介质，还包括用于接收所述增益信息和所述 选通控制信息的程序代码。
72.根据权利要求70所述的计算机可读介质，其中，所述发送选通控制和所述接收选通控制是所述射频前端(RFFE)的一部分。
73.根据权利要求70所述的计算机可读介质，还包括用于执行以下步骤中尚未执行之 第二步骤的程序代码a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
74.根据权利要求73所述的计算机可读介质，还包括用于执行以下步骤中尚未执行之 最后步骤的程序代码a)发送所述第一期望时间戳和所述增益信息到所述射频前端(RFFE)；b)发送所述第二期望时间戳和txEnable命令到所述发送选通控制；或者c)发送所述第三期望时间戳和rxEnable命令到所述接收选通控制。
75.根据权利要求74所述的计算机可读介质，其中，所述发送选通控制和所述接收选 通控制是所述射频前端(RFFE)的一部分。
76.根据权利要求70所述的计算机可读介质，其中，所述射频前端(RFFE)的增益的改 变发生在基于所述增益信息的期望时间的+/_2微秒内。
77.根据权利要求76所述的计算机可读介质，其中，所述期望时间是增益改变生效的 时间。
78.根据权利要求70所述的计算机可读介质，还包括用于将以下各项中的至少一项 复用到采样流的程序代码第一期望时间戳、第二期望时间戳、第三期望时间戳、增益信息、 txEnable 命令或 rxEnble 命令。
79.根据权利要求78所述的计算机可读介质，其中，所述增益信息(rxGain)定义为rxGain =四舍五入((Pout-Pin) *2)，其中，Pin是在天线端口处对接收功率的估计，Pout由下式给出Pout = 101og(o 2)其中，ο 2是所述采样流的平均平方数字值。
80.根据权利要求79所述的计算机可读介质，其中，所述增益信息(rxGain)代表以 0. 5dB步进的期望增益。
全文摘要
用于采样同步的装置和方法，包括从射频前端(RFFE)接收返回链路(RL)时间戳；从导航和定时系统接收系统时间秒；基于RL时间戳和系统时间秒生成前向链路(FL)时间戳；并将FL时间戳和系统时间秒包括到时间数据中。在一个方面，该装置和方法用于进行RF控制，其包括在存储器中存储增益信息和选通控制信息；并执行以下一个或多个步骤发送第一期望时间戳和增益信息到射频前端(RFFE)；发送第二期望时间戳和txEnable命令到发送选通控制；或者发送第三期望时间戳和rxEnable命令到接收选通控制。
文档编号H04W56/00GK101904205SQ200880121411
公开日2010年12月1日 申请日期2008年12月20日 优先权日2007年12月20日
发明者S·乌帕拉 申请人:高通股份有限公司