Iu-UP-Status Iu-UP-UNIT- DATA Indication Indication Request Request Indication Iu-UP-control Iu-UP-payload Iu-UP-control Iu-UP-Procedure-Control Iu-UP-Procedure-Control Iu-UP-payload Iu-UP-payload SDU RFCI Subflow 1 SDU, ..., Subflow n SDU RFCI FQC Error Cause, Error distance Initialisation RFCI indicators, Downlink send intervals (when applicable) Time Alignment Error Cause Time Alignment ACK/NACK
原语的使用是Iu UP协议操作模式的功能。表2说明了Iu UP原语与Iu UP操作模式间的关系。
表6:与Iu UP操作模式及与操作模式功能相关的Iu UP协议层业务原语
Primitive Type Mode of Operation Iu-UP-DATA Request SMpSDU Indication SMpSDU Iu-UP-Status Request SMpSDU Indication SMpSDU Iu-UP-UNIT-DATA Request TrM Indication TrM 7.2.2 Iu-UP-DATA-REQUEST
高层利用该原语向Iu NAS数据流实体，请求在已建立的传输连接上，发送RAB Subflow SDU（s）。该原语也包含了原语中净荷的RFCI。
Iu UP帧协议层形成Iu UP数据帧（Iu数据流DU是Iu UP帧的净荷），并以低层提供的业务方式传输该帧。 7.2.3 Iu-UP-DATA-INDICATION
该原语作为一种指示，向高层实体传送所接收的Iu UP帧的Iu NAS数据流用户平面信息。 该原语也包含净荷信息的RFCI。
在RNL-SAP，该原语可以包括帧质量分类指示。
该原语也可能包含一种信息，该种信息用于向高层指示与原语中净荷相关的故障状态。 7.2.4 Iu-UP-STATUAS-REQUEST
该原语用于要求报告已经检测到的错误。 该原语也用于时间对准的肯定与否定确认。 7.2.5 Iu-UP-STATUS-INDICATION
该原语用于向高层实体报告已经检测到故障。涉及故障的信息由异常事件信息表示，并发往高层。
该原语也用于初始化控制过程，向高层Iu DS层传送一些信息，如：用于通信阶段的RFC集合及相关的RFCI。
该原语用于向高层指示Iu上的反向允许的速率集合。允许的速率集合由RFCI指示和（当适用时）下行链路发送时间间隔表示。
当一帧作为帧质量分类处理的结果被丢弃时，该原语向高层于指示。
35
该原语也用于向高层指示时间对准信息，即：发送帧应提前或滞后的时间。 7.2.6 Iu-UP-UNIT-DATA-REQUEST
高层实体利用该原语请求在已建立的传输连接上，传输Iu UP净荷。
Iu UP协议层利用低层提供的业务方式，传送Iu数据流DU，而不增加任何协议头部信息。 7.2.7 Iu-UP-UNIT-DATA-INDICATION 该原语用于向高层实体传送Iu UP净荷。 7.3 在TNL SAP指向传输层的原语 7.3.1 概述
对传送网络层的访问是通过TNL SAP实现的。
当传送网络高层包含AAL2时，TNL SAP映射到AAL-SAP。通过该SAP的通信使用特定的AAL原语实现。
当传送网络高层包含GTP-U时，TNL SAP映射到GTP-U SAP。通过该SAP的通信使用通用 原语实现。 在TNL SAP， 特定或通用通信方式的选择由无线网络层控制平面逻辑确定。这种选择是基于以下的内容，如：RAB特性提出的要求、请求RAB建立的CN域或其他运营商的选择。 7.3.2 基于ATM/AAL2的传输层 7.3.2.1 概述
当Iu UP协议层使用ATM/AAL2传输的业务时，它使用已建立的AAL2连接，在Iu UP接入点两端的对等TNL SAP传输 帧。Iu的传送网络控制平面处理建立及释放AAL2呼叫连接的信令。 7.3.2.2 Iu UP协议使用的AAL2业务原语
表3说明了在AAL2 SAP使用的AAL2业务和原语。
表7AAL2原语及参数
Not used（Note ） （Note 1： 该域设置为不用，即按照《ITU-T Recommendation I.366.1》为 十进制的26。） 表3中的原语是【8】中的标准原语 ，这些原语准备用于Iu UP。 7.3.3 在TNL SAP（GTP-U传输层）的原语 7.3.3.1 概述
当Iu UP协议层使用GTP-U的传输业务，它利用已经建立的GTP-U隧道，在Iu UP接入点两端的GTP-U隧道终点之间传送帧。Iu的RANAP控制平面信令处理GTP-U隧道建立及释放信令。 7.3.3.2 Iu UP协议使用的通用业务原语
通用原语用于GTP-U SAP。表4列出这些原语。
表8:与GTP-U层有关的通用原语及参数
Primitive SSSAR- UNITDATA SSSAR- UNITDATA Type Request Inidication Parameters SSSAR-INFO SSSAR-UUI SSSAR-INFO SSSAR-UUI Comments Not used（Note） Primitive Iu-UP-UNITDATA Iu-UP-UNITDATA Type Request Indication Parameters Iu-UP-paylaod Iu-UP-payload Comments 36
8 Iu UP协议的演进
8.1 协议演进的原则 8.1.1 未知域数值
通过使用目前规定的保留值和空闲值，Iu UP协议可以进行演进。当一个用户平面实体接收了一个未知区数值，可以根据未知数值是属于保留还是空闲，采取不同的动作。对接收方动作的建议如下所述：
- 如果发送方使用空闲值，但接收方不能理解，接收方应有默认的动作。默认的动作在域的基础上定义； - 如果发送方使用保留值，但接收方不能理解，接收方应拒绝该值。如果可能，通过向对等实体发送一个否定确认实现。否则，应生成一个错误报告，以通知高层和对等实体；
- 一个接收的错误事件消息不触发另一个返回发送方的错误事件消息，即使，如：收到的错误事件消息中的原因值不被理解。
下面的内容将说明：当收到一个未知域数值时，建议的接收方动作如何按域的顺序处理。 PDU类型 取值范围：0 ~ 1：in use，2~13：reserved for future use，14：in use，15 ：reserved for future use 如果使用保留值，推荐动作：产生一个错误事件，即：通知高层和对等实体错误事件，原因为：Unknown PDU Type。 FQC 取值范围：0~1：In use，2~3：spare
如果使用空闲值，推荐动作：忽略该域，将其向前传送。 Ack/Nack 取值范围：0 ~2：in use，3：reserved
如果使用保留值，建议动作：产生一个错误事件，即：通知高层和对等实体错误事件，原因为：Unknown reserved value。 Procedure Indicator 取值范围：0 ~3：in use，4~15：reserved
如果使用保留值，推荐动作：产生一个错误事件，即：通知高层和对等实体错误事件，原因为：Unknown procedure。
Error Cause value 取值范围：0：reserved，1、16：In use，2~15 and 7 ~255：spare
如果使用保留值，推荐动作：产生一个错误事件，即：通知高层和对等实体错误事件，原因为：Unkown reserved value。
如果使用空闲值，推荐动作：忽略该域，将其向前传送。 8.1.2 在已有的帧中增加一个新域
如果需要在一个已存在的过程中增加一个新的域，需要应用以下原则：
- PDU类型定义头部模板。因此，一个新域不要在已有帧的头部增加，不考虑头部的可能空闲比特，因为这会对头部模板造成损坏； - 过程指示定义控制帧中的域； - 对于每个过程，只有一个过程指示；
- 如果需要在一个已有过程中引进一个新域（即：在已有的UP版本中定义的已有过程），新域将不在净荷部分增加。如果可能，新域可以在帧净荷的空闲部分加入；
37
- 当一个已有帧需要引进一个新域时，但净荷中的空闲域不能引进新域，则创建一个新的过程，并给该过程分配一个新的过程指示；
- 使协议演进简单，当引进新的过程指示时，新帧应包括新域和旧帧的域；
- 当接收了一个未知的过程指示，它可以使用错误事件消息报告，原因为：Unknown procedure 。这向发送方说明该过程不能被理解，它可能试用旧的过程。
8.1.3 增加新的PDU类型
在未来Iu UP协议可能演进以致需要增加新的PDU类型。引进新的PDU类型的准则可能是：
- 过程指示可能用完，需要增加；
- 需要更改头部模板，如：帧号域可能需要增加或CRC域需要更改。
当PDU类型14用于未来PDU类型扩展时，在PDU类型14下可能有“子类型”，在这些“子类型”中也可能有新的过程。
因此必须保证：如果相同的过程指示值用于几个PDU类型，需要明确其相关的PDU类型，如：在错误事件原因中。 8.1.4 协议版本处理
在未来可能会引进新的的Iu UP协议版本，其原因可以是：
- 早期引进的新特性或功能在新版本中要求是必需的；
- 由于技术的发展，协议的新版本可能完全不同（和兼容）于早期版本。
在Iu UP协议版本处理上，应采用以下原则：
- 可以引入附加的操作模式； - 可以各自独立地演进操作模式；
- 对于每个操作模式，可以有独立的版本号；
- Iu UP协议实例的操作模式由CN决定，但RAB指配和迁移资源分配过程中，模式的版本应在CN与UTRAN之间协商；
- UP操作模式的版本号在不同Release之间可以变化或不变； - 当协议演进时，需要在规范中标明哪些特性 属于哪个版本； -
一个新的版本可以是老版本的演进（即：兼容）或与老版本完全不同。
38
