基于TD-LTE的集群通信系统的研究1018-接受修订(合稿1021)

YD/T××××—2004YD/T××××—2004图64所示，其中NetworkA、NetworkB和NetworkX可以属于同一个网络也可以是不同的网络。图STYLEREF1\s6SEQ图\*ARABIC\s14PoC控制功能服务器、PoC参与功能服务器、PoC客户端之间关系PoC控制功能要求实现：提供集中的PoC会话处理；能够为PoC会话指派和应用QoE属性数据；提供集中的媒体分发；提供集中的媒体流控制功能，包括发言者标识；支持媒体流控制协议MBCP，媒体流控制协议协商和媒体流控制过程；为PoC会话提供指定策略或者策略执行；提供参与者信息；为会话参与者提供PoC地址隐私；提供集中的计费报告；支持被邀请用户标识信息；支持离散媒体。除此之外，PoC控制功能可以实现：支持不同编码格式之间的编码转换；支持PoCBox处理；支持全双工呼叫处理；支持携带媒体内容的请求消息；支持Dispatch会话；支持运营商信息提醒；支持用户面适配；支持媒体控制策略；支持媒体传输优化；根据PoC会话的QoE属性数据为媒体划分不同的优先级；支持媒体缓存能力、本地授权模式等性能增强功能。PoC参与功能要求实现：提供PoC会话处理；支持为每个PoC会话应用QoE属性数据；提供入呼叫PoC会话的策略增强；支持媒体流控制协议和媒体流控制协议协商；支持存储当前的PoC业务设置；支持为参与者生成计费报告；会话建立时被叫侧的PoC参与服务器要提供主叫PoC用户的PoC地址隐私保护；支持被邀请用户标识信息。如果PoC参与服务器在媒体传输的通路上，那么PoC参与服务器还应该实现：在PoC客户端和PoC控制服务器之间中继媒体报文；支持媒体流控制协议并且能够在PoC客户端和PoC控制服务器之间转发媒体流控制消息；收集并提供媒体质量反馈信息。除此之外，PoC参与功能可以实现：支持携带媒体内容的请求消息；支持PoC与外部P2T网络互通；支持用户面适配；支持运营商信息提醒。如果PoC参与服务器在媒体传输的通路上，那么PoC参与服务器还可以：在多个并发会话中提供媒体过滤功能；提供不同编码格式之间的编码转换；根据PoC会话的QoE属性数据为媒体划分不同的优先级；提供媒体传输优化功能。SIP/IPCoreSIP/IPCore包括若干SIP代理和SIP登记器，主要是在PoC客户端和服务器之间路由SIP信令，并执行以下功能：提供搜索和地址解析服务；支持SIP压缩；基于用户配置，执行鉴权和授权（对PoC客户端）；维护登录状态；在控制平面提供对标识隐私的支持；提供计费信息；提供合法监听功能。接入网可以支持部分的合法监听的功能。当SIP/IPCore是基于3GPPIMS或者3GPP2MMD，那么相应的SIP/IP核心请分别参见TS23.228[25]或者X.P0013.2[24]。地址和标识每个PoC用户在网络中必须有一个或者多个PoC地址，PoC地址被PoC用户用来与其他PoC用户进行通信，作为PoC用户的标识，PoC地址可以是SIPURI或者TELURI，但至少要有一个SIPURI，PoC地址的格式要遵从RFC3261（SIPURI）或者RFC3966（TELURI）。PoC地址必须在SIP/IPCore中注册，可以同时注册多个PoC地址，这些地址可以被用来提供PoC业务或者其它基于SIP的业务。下面是可以使用的PoC地址实例：sip:joe.doe@；sip:buss2.city@；sip:buss2.city@；tel:+16195551212；tel:5551212;phone-context=。PoC群组使用PoC群组标识来代表，PoC群组标识关联到群组中每个群组成员的PoC地址，也可以关联到其他群组，也就是说，PoC群组中可以包括其他PoC群组。PoC群组的创建可以有多种方式，例如运营商静态地创建PoC群组或者PoC用户动态创建PoC群组。PoC群组标识必须是符合RFC3261的SIPURI格式。PoC用户可以通过其他PoC用户或者群组的SIPURI来寻找定位要通信的对象建立会话，如果是PoC用户使用了TELURI，那么PoC服务器可以将TELURI转换成SIPURI。PoC服务器和PoC客户端可以在消息中使用用户的昵称。如果主叫PoC客户端支持使用昵称，可以在请求消息中携带主叫用户的昵称，如果被叫PoC客户端支持使用昵称，可以在请求响应消息中携带被叫用户的昵称。PoC服务器将收集、保存并维护主叫用户和被叫用户的昵称信息，如果某个昵称在PoC会话中出现多次，那么PoC服务器应该重新设置PoC用户的昵称以保证每个用户有唯一的昵称标识，例如PoC服务器可以设置PoC用户的昵称为“NickName-n”，其中n是个自然数。PoC通信模式PoC业务可以提供多种通信模式，包括PoC用户之间的点到点（1－1）模式、点到多点（1－M）模式、点到多点到点（1－M－1）模式。通信可以有多种媒体类型，包括语音、音频、视频等，使用每个PoC客户端中包含的媒体流控制实体（逻辑实体）完成，通信过程中使用媒体流控制过程同时只能有一个用户发送媒体流，被邀请用户可以选择自动接听或者手动应答呼入邀请。在点到点模式下，一个PoC用户可以与另外一个PoC用户建立通信，点到点的PoC会话在媒体流控制实体之间进行，与媒体流控制实体关联的连续媒体或者离散媒体使用半双工方式互通，而若没有与媒体流控制实体关联的离散媒体则可以使用全双工方式。在点到多点模式下，与媒体流控制实体关联的连续媒体或者离散媒体使用半双工方式互通，而没有与媒体流控制实体关联的离散媒体可以使用全双工方式，媒体发送方发出的媒体可以传递到多个参与用户，每个用户也都可以接收到来自会话中其他参与者发送的媒体。点到多点是各种群组会话默认的通信模式。点到多点通信模式应该支持三种群组：预定义群组、临时群组、聊天群组。预定义（pre-arranged）群组的特性：当群组中的一个用户邀请群组中其他成员时，会话就会建立。当群组中的第一个成员接受邀请并且PoC群组会话建立的发起者接收到发言权指示后，通信开始。预定义群组的参与者仅限于群组的成员。成员可以在会话开始的时候被邀请加入或者在会话进行过程中加入。成员可以邀请群组的其他成员用户加入正在进行的群组会话。临时（ad-hoc）群组的特性：当PoC用户选择多个用户并邀请了他们时，临时群组会话建立。当第一个用户接受邀请时，语音通信开始。收到临时群组会话成员的邀请后，用户才能够加入临时群组会话。作为例外，之前收到过邀请的用户可以重新加入（比如：用户拒绝了邀请，离开会话等）。聊天群组（chatgroup）的特性：只要有一个PoC用户加入，聊天PoC群组会话就建立。群组会话建立后，原则上就可以开始发送/接收媒体。PoC用户应能够建立一个聊天PoC群组会话，或者加入到一个正在进行的聊天PoC群组会话中。PoC用户可以被邀请加入某个聊天PoC群组会话。聊天PoC群组的参与，可以是受限或不受限制。在点到多点到点模式下，与媒体流控制实体关联的连续媒体或者离散媒体使用半双工方式互通，而没有与媒体流控制实体关联的离散媒体可以使用全双工方式，这一点与其他两种通信模式相同。在点到多点到点模式中，存在一个特殊参与用户，作为PoC会话的特殊节点，其他会话参与用户作为普通用户。所有的用户都可以收到媒体流控制信令，但是普通用户只能接收到来自特殊用户的媒体流，也只有特殊用户才能够接收到来自其他普通用户的媒体流，也就是说，普通用户只能向特殊用户发送媒体流并且只能从特殊用户接收媒体流。点到多点到点是一种可选的通信模式，可以用在预定义群组或者调度员群组等场景。会话建立PoC会话可以分为两种，随选（On-demand）会话和预建立（Pre-established）会话，PoC会话也可以分为点到点会话或者点到多点会话。随选会话是一种在会话建立过程中进行媒体参数协商的PoC会话建立机制，预建立会话是指PoC用户在与其他PoC用户建立会话之前，先在PoC客户端和归属的PoC服务器之间建立的会话。PoC预建立会话应该在PoC客户端和归属PoC服务器之间协商媒体类型和媒体参数，根据用户发送的会话建立请求，在该用户和PoC服务器之间预先建立一个或者多个预建立会话，并且此时预建立的会话所协商的会话能力为未激活；当PoC服务器接收到PoC用户发送的业务请求后，根据该业务建立请求中携带的选择信息和已经建立的预建立会话来建立实际使用的会话，在建立实际会话的过程中，激活预建立会话协商的会话能力，PoC会话即可以被业务所使用。PoC会话的建立过程是由发起会话的PoC客户端向SIP/IPCore发送会话建立请求，并且在会话建立请求中指示需要使用PoC业务进行通信，这样SIP/IPCore就可以把会话建立请求转发给发起PoC服务器。会话发起方应该在会话建立请求中携带支持的媒体类型，在PoC业务中，会话可以使用多种媒体类型，为了确保会话参与方有共同支持的媒体类型，会话请求中应该至少包含语音媒体类型。发起侧PoC服务器收到会话建立请求后首先进行必要的业务控制，如果有需要发起PoC服务器还可以将会话建立请求转发给其他PoC服务器。PoC服务器完成业务控制后，将会话建立请求发送给SIP/IPCore，同样指示需要使用PoC业务进行通信，SIP/IPCore即可以把会话建立请求转发给终结PoC服务器。终结侧PoC服务器收到会话建立请求后进行终结侧业务控制，之后将会话建立请求转发给接收会话的PoC客户端，PoC客户端接收会话建立请求后返回会话建立响应，即完成了会话建立过程。PoC会话建立过程同时也是会话媒体协商过程。发起侧PoC客户端发出会话邀请消息，其中可以携带多个媒体参数，如，媒体类型（包括媒体类型的组合）、媒体格式、IP地址和端口号。被叫侧PoC客户端接收到会话邀请消息后，选择其中的媒体参数，生成应答消息。PoC服务器接收到被叫侧PoC客户端返回的协商结果后，保存协商结果，对主叫用户应答，并将PoC客户端支持的媒体参数信息通知给其他会话参与用户。会话建立完成后PoC服务器或者PoC客户端还可以进行会话修改，例如可能是媒体类型或者其他媒体参数发生了变化，需要注意的是应该尽量避免在媒体流传送的同时进行会话修改。在点到点的PoC会话中，主叫PoC用户邀请其他PoC用户参加点到点会话，PoC服务器可以在被叫用户响应邀请之前向主叫PoC用户提供预先发言指示，主叫方可以保持或者终止PoC会话（如因为被叫方应答时间太长而拒绝被叫方），如果被叫方接受了邀请，主叫方应该收到一个指示，表示被叫方已经接受了邀请，在接收到服务器发送的可以发言指示后，主叫方可以发言或者发送媒体，否则主叫方不能发言或者发送媒体。在点到多点的PoC会话中，又可以分为预定义群组和临时群组两种情况。媒体流控制由于PoC业务的半双工特性，PoC客户端在发送媒体流之前必须要先协商取得发言权，这就是媒体流控制，语音、音频、视频等连续媒体应该通过媒体流控制，离散媒体可以通过媒体流控制。媒体流控制的过程是PoC客户端在发送媒体前先向PoC服务器发送发言允许请求，如果没有其他用户发言PoC服务器就向请求的PoC客户端发回发言允许，此时Poc客户端就可以发送媒体；如果此时有其他用户正在发言，PoC服务器可以将发言请求放进申请队列排队或者如果PoC服务器不支持排队拒绝客户端的发言请求。PoC业务还支持使用优先级，已经定义了以下几种：抢占优先级（Pre-emptivepriority），可以中断其他优先级用户的发言直接获得发言权；高优先级（Highpriority），可以在发言权释放后在发言权申请队列中优先获得发言权；普通优先级（Normalpriority），发言权释放后，如果没有其他优先级发言请求，可以在发言权申请队列中获得发言权；仅接收优先级（Receive-only），仅接收优先级PoC用户只能接收媒体。如果PoC客户端和PoC服务器支持请求队列，那么还可以使用媒体流请求队列位置状态消息（MediaBurstrequestqueuepositionstatusmessage），消息中可以携带请求在队列中的位置和请求优先级指示等信息。当需要向发言请求队列中用户分配发言权时，PoC服务器会接收到操作请求改变存放发言请求消息队列的状态，例如排在队首的发言请求被调出分配发言权，PoC服务器需要对请求排队队列进行调整。PoC服务器在调整请求队列之后应该向该队列对应的群组内的PoC用户客户端发送包含此次调整操作导致的队列变化的通知消息。如果PoC客户端修改媒体发送请求并且发送请求标识信息和修改目标描述信息至PoC服务器，PoC服务器接收到请求后根据标识信息确定媒体发送请求已经在请求队列中存在，并且需要修改，PoC服务器将根据接收到的修改目标描述信息对所述需要修改的媒体发送请求进行修改。修改目标描述信息可以包括：修改后的媒体发送请求的请求优先级、队列中的位置。PoC客户端也可以指定向部分会话参与者发送媒体流，PoC服务器在建立PoC会话时会保存各个会话参与者的会话信息，包括会话参与者信息、媒体传输地址信息以及各项信息之间的关联。PoC用户在向PoC服务器发送媒体流时可以携带希望接收此媒体流的接收用户的信息，PoC服务器收到该媒体流时将根据其中的接收用户信息，将媒体流分发至指定的会话参与者。媒体流控制分配发言权时可以使用临时发言权，当会话中有PoC用户正在发言时，其余希望发言的用户通过向PoC服务器发送发言权申请可以立即获得临时发言权，进行发言，PoC服务器应该根据申请临时发言权用户的发言请求和服务器的本地策略，授予用户相应的临时发言权。申请临时发言权的用户发言结束后，向PoC服务器发送释放临时发言权消息，PoC服务器将发言权重新分配给原正在发言的PoC用户。并发会话PoC客户端和PoC服务器可以同时处理多个PoC会话，如果他们支持这一特性。处理多个同时进行的会话意味着归属的PoC服务器能够为了某个单个的会谈而丢弃其余的PoC会话的媒体流，所有的PoC会话都应该包括一个SIP会话、媒体流控制以及PoC客户端和归属PoC服务器之间的媒体流。PoC客户端应该指示给归属的PoC服务器是否支持并发媒体处理，支持并发媒体处理的PoC客户端应该可以为PoC会话设置优先级，PoC会话共有两种优先级等级，主要的和次要的，全部的PoC会话中最多只能有一个PoC会话是主要PoC会话，其余的都是次要PoC会话。PoC服务器可以根据PoC会话的优先级等级选择过滤发送给PoC客户端的媒体，除此之外，PoC客户端还可以保持到某一个选定的PoC会话，或者反之解除保持。PoC会话的主要/次要优先级是针对PoC用户和PoC会话的，PoC会话的优先级保存在归属的PoC服务器上，PoC客户端可以在会话建立或者更新时设置PoC会话的优先级，也可以在多个会话进行中改变PoC会话的优先级，如果PoC客户端选择保持某个选定的PoC会话，那么归属PoC服务器将不再发送其他PoC会话的媒体给PoC客户端。归属PoC服务器收到主要PoC会话的媒体后应该立即转发给PoC客户端，即使是此时PoC服务器正在向PoC客户端发送次要PoC会话的媒体，但是当PoC客户端正在向归属PoC服务器发送次要PoC会话媒体时，PoC服务器即时收到要发送给PoC客户端的主要PoC会话媒体也不能打断PoC客户端正在发送的媒体流，此时PoC服务器应该发送媒体流控制消息给PoC客户端。对于并发会话中PoC用户不接收的媒体类型，发送媒体的PoC用户建议可收到对方拒绝接收的状态信息。因此同时参与多个并发会话的PoC用户，需要设置媒体类型的接收或者拒绝状态，可以由PoC用户设置呈现拒绝接收的状态信息，或可以由PoC服务器设置呈现拒绝接收的状态信息。PoCBoxPoC业务可以使用两种PoCBox：终端PoCBox或者网络PoCBox，用于被邀请的PoC用户存储PoC会话数据或者PoC会话控制数据。当终端PoCBox和网络PoCBox都可用时，选择PoCBox取决于PoCBox接入规则设置。发起邀请的PoC用户可以选择是否接受会话被转发至PoCBox存储。对于发起邀请的PoC用户，可以显式地设置：PoC会话邀请可以直接发送至被邀请用户的PoCBox，在主叫用户和被邀请用户的PoCBox之间建立会话；或者PoC会话邀请只发送至被邀请用户，不包含被邀请用户的PoCBox。对于被邀请的PoC用户，可以在PoC业务设置中设定自己的PoCBox的功能、参数，是否愿意将会话邀请转发至PoCBox或者向PoCBox转发会话邀请的条件。转发会话邀请到PoCBox的条件可能是：PoC用户设置了手动应答模式，并且PoC服务器转发会话邀请后一定时间内没有收到被邀请PoC客户端的振铃响应；PoC用户设置了手动应答模式，并且PoC服务器转发会话邀请后一定时间内没有收到被邀请PoC客户端接受或者拒绝的响应；PoC用户设置了自动应答模式，并且PoC服务器转发会话邀请后一定时间内没有收到被邀请PoC客户端接受或者拒绝的响应；PoC客户端正在参与另外一个PoC会话；PoC用户设置了呼入会话闭锁激活。如果PoC用户设置了无条件转发会话邀请到PoCBox，那么所有的呼入会话都将被转发给PoCBox。被邀请用户所属的PoC服务器收到来自主叫用户的会话邀请后，根据PoC业务设置和PoCBox接入规则，进行必要的业务及路由控制，如果需要则将会话邀请转发至PoCBox。当PoCBox接收到会话邀请后，将接受邀请并且在返回的响应消息中指示PoCBox标志。PoC服务器接收到带有PoCBox指示和PoCBox类型的响应消息，应该将PoCBox指示和PoCBox类型转发给主叫PoC客户端。主叫PoC客户端收到后应该显示给PoC用户，与被邀请用户的PoCBox建立PoC会话，并且如果有足够的信息也可以通知PoC用户被叫方使用的是终端PoCBox还是网络PoCBox。还有一种情况是被邀请的PoC客户端不希望接入新的会话，也可以将会话邀请重定向路由到PoCBox。PoCBox收到会话邀请后，应该接受会话邀请并且返回响应消息，消息中携带PoCBox指示、联系地址、媒体协商应答，PoCBox还应该支持媒体流控制协议。当PoCBox接收到媒体流，应该能够存储媒体流，以及发送方的PoC地址、日期、时间，对于网络PoCBox，还应该能够在PoC用户的控制下，发送PoC会话数据或者发送媒体。对于已经存在的现有PoC版本的PoC客户端与PoCBox之间的通信，PoC客户端邀请PoCBox，可以在网络功能实体（例如PoC服务器）的控制下，根据参与用户终端发送的版本信息，判断主叫用户终端是否能够识别被叫侧发出的各种业务信息，如果不能，网络功能实体将提供中间转换功能生成主叫用户终端能够支持的业务信息，这时主叫用户终端再接收能够支持的业务信息。这里的业务包括PoC业务、会议业务、消息类业务、呈现类业务等，主叫用户终端在接收到能够支持的业务信息前不能获得业务发言权。调度员Dispatcher功能PoC客户端和PoC服务器可以支持调度员（Dispatcher）功能，授权的PoC用户可以创建调度员群组并且在共享群组服务器中保存，调度员群组属于预定义群组。调度员群组在创建的时候可以指定群组中每一个成员是否可以作为调度员，群组中至少要有一个成员可以作为调度员，可以有多个群组成员能够作为调度员，但是在任一时刻只能有一个群组成员作为激活的调度员，调度员以外的用户是FleetMember。调度员在发起会话建立的时候可以在邀请中指明自己的调度员角色，这样PoC服务器可以建立调度员群组会话，按照以下的规则：邀请整个PoC群组，如果会话邀请没有列出邀请的对象，那么PoC控制服务器应该邀请所有的FleetMember，其余能够作为调度员的群组成员可以被邀请；邀请部分群组成员，如果会话邀请中列出了单独的成员，那么PoC控制服务器应该检验这些成员是否属于调度员群组并且只邀请这些用户加入会话；如果PoC控制服务器收到会话邀请时已经有调度员群组会话建立成功，那么PoC控制服务器应该拒绝此次会话邀请并且指明原因；如果PoC控制服务器收到一个邀请调度员群组子群组的会话邀请，并且此时已经有调度员群组会话或者另外一个调度员群组子群组会话建立成功，那么：如果发起本次邀请的PoC用户也是另外PoC调度员群组会话的调度员，那么PoC控制服务器应该建立一个并行的调度员群组会话，使用唯一的会话标识符标识；如果发起本次邀请的PoC用户不是另外PoC调度员群组会话的调度员，那么PoC控制服务器应该拒绝本次邀请。当作为调度员邀请一个PoC客户端时，PoC控制服务器应该在邀请中显式地向PoC客户端指示出调度员角色；PoC控制服务器应该在调度员群组会话邀请和会话建立确认中指示出调度员角色。能够作为调度员的PoC客户端应该支持多个并发PoC会话，PoC调度员可以和不同的调度员群组建立并发的调度员群组会话。调度员群组会话建立成功之后，激活的PoC调度员可以将调度员角色转交给其他PoC用户，FleetMember应该可以通过订阅信息来获知调度员群组中调度员角色的转移。信令压缩PoC客户端和SIP/IPCore应该支持SIP信令压缩，压缩的规则按照RFC3320，RFC3485，RFC3486的规定以减少传输时延。如果PoC客户端按照RFC3320，RFC3485，RFC3486的规则发起SIP信令压缩，SIP/IPCore应该按照RFC3320，RFC3485，RFC3486的规则压缩SIP信令。推荐PoC客户端和SIP/IPCore支持动态压缩或者其他信令压缩扩展操作，以提高信令压缩的效率并且进一步减少传输时延。计费PoC计费支持基于订阅的计费或者基于业务流量的计费。基于订阅的计费中，类似用户业务属性和业务激活时间等信息被传输到计费系统进行计费，用户的标识可以使用IMSI，MSISDN或者其他能够被现有计费设备使用的标识。基于业务流量的计费中，可以使用在线（online）计费和离线（off-line）计费，PoC业务计费数据和业务使用的数据报文之间的关联是通过在CDR中增加底层网络创建的数据报文标识信息。如果PoC会话涉及到多个不同的运营域，那么每个网络的标识信息和计费标识也被记录在CDR中。在实现计费的过程中，PoC控制服务器在PoC会话开始时，需要为参与该会话的主叫用户和被叫用户分配相同且唯一的PoC计费标识，并且需要将PoC计费标识分别传送给主叫用户和被叫用户所属的IMS网络，将主叫用户和被叫用户通过该PoC计费标识关联。与此同时，主、被叫用户所属的IMS网络也需要生成IMS计费标识，并传递给PoC服务器进行关联。PoC业务提供商如果提供了网络PoCBox，也可以根据网络PoCBox中用户使用的存储空间进行计费。PoC业务实体可以根据PoCBox的存储空间变化触发计费，并且计费信息经计费信息传输接口传送至计费功能实体，进行基于PoC用户存储空间的计费处理。漫游PoC客户端在漫游时应该可以使用归属网络的PoC业务，以个体或者PoC群组会话参与者的身份。在漫游或者不同运营商的网络互联时，PoC服务器和PoC客户端应该：通过IP接入网的互联，或者漫游网络和归属网络之间存在SIP/IPCore的互联。详尽的互联机制可以参见3GPPTS23.228和3GPP2X.S0013.2。合法监听PoC业务和所使用的底层网络，应该在被要求时能够向合法监听中心提供足够的信息，即时有PoC用户请求使用PoC地址隐私，合法监听中心也应该可以获取全部PoC会话参与者的PoC地址信息。PoC网络应该提供必要的合法监听要求。操作维护子系统操作维护子系统包含故障管理，业务、信令等跟踪管理，性能管理和安全管理等。接口PoC子系统接口PoC系统中各个接口的用途及协议见REF_Ref274643297\h表6-1PoC子系统接口与协议。表SEQ表\*ARABIC6-1PoC子系统接口与协议ReferencePointUsageProtocolPOC-1PoC客户端与SIP/IPCore之间的信令接口SIPPOC-2PoC服务器和SIP/IPCore之间的信令接口SIPPOC-3PoC服务器和PoC客户端之间的媒体、媒体流控制接口RTPRTCPMSRP连续媒体传输使用RTP协议，媒体流控制协议使用RTCP的APP消息协议，离散媒体使用MSRP协议。POC-4网络之间的媒体、媒体流控制接口RTPRTCPMSRP连续媒体传输使用RTP协议，媒体流控制协议使用RTCP的APP消息协议，离散媒体使用MSRP协议。POC-9终端PoCBox与SIP/IPCore之间的信令接口SIPPOC-10终端PoCBox与PoC服务器之间的媒体、媒体流控制接口RTPRTCPMSRP连续媒体传输使用RTP协议，媒体流控制协议使用RTCP的APP消息协议，离散媒体使用MSRP协议。POC-11网络PoCBox与SIP/IPCore之间的信令接口SIPPOC-12网络PoCBox与PoC服务器之间的媒体、媒体流控制接口RTPRTCPMSRP连续媒体传输使用RTP协议，媒体流控制协议使用RTCP的APP消息协议，离散媒体使用MSRP协议。POC-13PoC服务器与共享XDM服务器之间的接口，可以是共享列表服务器、共享群组服务器或者共享策略服务器XCAPXDM-1XDM客户端与SIP/IPCore之间的接口参见[XDMV2.0AD]XDM-2共享XDM服务器与SIP/IPCore之间的接口参见[XDMV2.0AD]XDM-3XDM客户端与聚合代理之间的接口参见[XDMV2.0AD]XDM-4聚合代理与共享XDM服务器之间的接口参见[XDMV2.0AD]PRS-1呈现源与SIP/IPCore之间的接口参见[PresenceV1.0AD]PRS-2观察者与SIP/IPCore之间的接口参见[PresenceV1.0AD]PRS-3SIP/IPCore与呈现服务器之间的接口参见[PresenceV1.0AD]PRS-5共享XDM服务器与呈现服务器之间的接口参见[PresenceV1.0AD]IP-1网络之间的会话信令接口SIPDM-1文档管理客户端与文档管理服务器之间的接口参见[OMA-DM]PB-1聚合代理与网络PoCBox之间的接口XCAP无线接入子系统和网络子系统S1-MME:EUTRAN和MME之间的接口，基于S1AP协议S1-U:EUTRAN和S-GW之间的接口，基于GTP-U协议S5:SGW和PGW之间的接口，基于GTP协议S11:MME和SGW之间的接口，基于GTP-C协议S10:两个MME之间的接口，基于GTP-C协议S6a:MME和HSS之间的接口Gx:PCRF和PCEF(PGW)之间的接口SGi:PGW和外部数据网络之间的接口Rx:AF和PCRF之间的接口集群业务流程注册注册和SIP会话无关，是向网络注册UE进入网络，表明UE支持PoC服务，并进行相关的协议协商，PoC服务器可以通过PoC-2接口来获得用户的注册信息，注册后UE就可以使用注册的PoC地址来和PoC服务器进行通信，其它的系统可以通过此地址进行寻址，可以同时注册多个PoC地址但显示注册的地址必须是SIP地址，由UE用re-register来保持注册的激活状态，UE可以在任何时候结束自己的注册状态。下图描述了PoC客户端向SIP/IPCore注册的过程。图STYLEREF1\s6SEQ图\*ARABIC\s15注册流程流程说明：1、PoC客户端向SIP/IPCore发送REGISTER请求，该请求的Contact头中应包含'+g.PoC.talkburst'；如果支持接收群组公告，则还应在Contact头中加上'+g.PoC.groupad'。2、SIP/IPCore向客户端A发送401“Unauthorized”响应,请求客户端注册消息的认证，在响应的WWW-Authenticate头部中包含认证质询。3、客户端再次发送REGISTER请求，在该请求的Authorization头中包含认证响应。4、SIP/IPCore向客户端发送200ok，肯定其注册成功。5、客户端A通过PUBLISH请求发布当前的PoC设置。6、SIP/IPCore将PUBLISH转发给PoC服务器A。7~8、服务器向客户端发送确认消息200OK9、服务器A为用户A保存PoC设置，即PUBLISH消息体里的内容。PoC预建立会话预建立会话的界定：INVITE中只有服务器地址而没有邀请对方。预建立会话是一个会话建立过程。是在客户端和本地网络之间建立的一个会话，在系统和客户端之间进行媒体参数、传输参数及发言权控制的协议参数协商。使得客户端在邀请其它的客户端加入会话或接受一个会话时不用再进行上述参数的协商。图STYLEREF1\s6SEQ图\*ARABIC\s16PoC预建立会话流程说明：1、终端A向SIP/IPcoreA发送INVITE请求，该请求中包含下列信息：参与功能URI（具体实现中可以是本地SERVERuri）；终端A非激活媒体流的媒体参数，包括RTP会话的IP地址和端口号、支持的编码格式、建议的发言权控制协议及端口号等等；PoC服务指示；终端A的用户PoC地址；发言权控制协议参数。2、SIP/IPcore根据INVITE消息中的PoC服务器地址，将INVITE消息发给PoC服务器A。3、服务器收到invite后检查有没有PoC服务标识，没有转5；查看INVITE中的请求URI是否能在服务器中找到，若不能，转5；再对用户进行认证鉴权，不通过转6，否则；检查媒体参数是否能接受，若不能，则转74、PoC服务器构造200OK并向SIP/IPcoreA发送200OK响应。该响应包含下列信息：PoC服务器A的媒体参数，包括PoC服务器的RTP会话的IP地址和端；口号，选择的媒体编码格式等等；一个用来标示预建立会话的会议URI；选择的发言权控制协议参数。5、服务器构造404NOTFOUND响应，发往SIP/IPcore6、服务器构造403FORBIDEN响应，发往SIP/IPcore7、服务器构造488NotAcceptableHere响应，发往SIP/IPcore8、SIP/IPcore将响应发送给终端A。PoC会话建立被叫端已经建立预建立会话时的PoC会话建立流程如REF_Ref274643904\h图67所示：图STYLEREF1\s6SEQ图\*ARABIC\s17PoC会话建立（被叫端已经建立预建立会话）1、PoC终端用户A向本地PoC网络发送一个INVITE请求来发起一个PoC会话2、SIP/IPcore根据消息中的PoC服务器地址，将INVITE消息转发给PoC服务器A.3、PoC服务器A收到INVITE请求后，进行处理。向SIP/IPcoreA发送INVITE请求。PoC服务器将自己支持的媒体类型和编码添加到SIPre-INVITE请求中。PoC的媒体类型和编码可以存储在PoC服务器自身或者通过其他服务器获得(如MRFC)。4、SIP/IPcoreA收到INVITE请求后，根据终端用户B的地址，将请求转发给SIP/IPcoreB.5、SIP/IPcoreB将INVITE请求转发给终端用户B的注册服务器PoC服务器B。6、由于PoC终端B采用的是预建立会话，服务器B向SIP/IPcoreB发送re-INVITE请求。PoC服务器B将自己支持的媒体类型和编码添加到SIPINVITE请求中。7、SIP/IPcoreB向PoC终端用户B转发re-INVITE请求8~12、PoC终端用户B发送180Ringing表明已收到re-INVITE请求13~14、PoC用户B接受请求后，验证媒体参数的有效性，若无效，发送488“NotAcceptableHere”给服务器。否则，终端B向服务器发送一个200OK响应15~17、服务器B向控制网络发送200OK消息18~19、当PoC服务器收到第一个被邀请用户的200OK响应后，会向终端用户A发送一个200OK消息。20、服务器A会向终端用户A发送talkburstconfirm通知终端A可以进行媒体传输了21、控制功能服务器收到该响应后，向PoC终端B发送receivingtalkburstindication。22、终端用户A发送媒体流。被叫端未建立预建立会话时的PoC会话建立流程如REF_Ref274643958\h图68所示：图STYLEREF1\s6SEQ图\*ARABIC\s18PoC会话建立（被叫端未建立预建立会话）1、PoC终端用户A向本地PoC网络发送一个INVITE请求来发起一个PoC会话。2、SIP/IPcore根据消息中的PoC服务器地址，将INVITE消息转发给PoC服务器A.3、PoC服务器A收到INVITE请求后，进行处理。向SIP/IPcoreA发送INVITE请求。PoC服务器A将自己支持的媒体类型和编码添加到SIPINVITE请求中。4、SIP/IPcoreA收到INVITE请求后，根据终端用户B的地址，将请求转发给SIP/IPcoreB.5、SIP/IPcoreB将INVITE请求转发给终端用户B的注册服务器PoC服务器B。6、由于PoC终端B采用的是on-demand会话，服务器B向SIP/IPcoreB发送INVITE请求，PoC服务器B将自己支持的媒体类型和编码添加到SIPINVITE请求中。7、SIP/IPcoreB向PoC终端用户B转发INVITE请求8~12、PoC终端用户B发送180Ringing表明已收到INVITE请求13~14、检查INVITE请求中媒体参数的有效性，若无效，则发送488“NotAcceptableHere”。否则，PoC用户B接受请求后，终端B向服务器发送一个200OK响应。15~17、服务器B向控制网络发送200OK消息18~19、当PoC服务器收到第一个被邀请用户的200OK响应后，会向终端用户A发送一个200OK消息。20、服务器A会向终端用户A发送talkburstconfirm通知终端A可以进行媒体传输了21、控制功能服务器收到该响应后，向PoC终端B发送receivingtalkburstindication。22、终端用户A发送媒体流时延及性能分析本分析包含集群业务建立时延和话权申请时延。未优化集群业务建立时延从主叫用户发起集群业务请求消息开始，到接收到网络下发的话权授权消息为止，之间的时间间隔被定义为集群业务建立时延。未优化的集群业务建立时延大约为1000ms，主要由以下时延部分组成。图STYLEREF1\s6SEQ图\*ARABIC\s19集群业务时延分析UE从空闲态转为连接态的时延参考36.912文档,UE的RRC连接建立时延从步骤1到步骤10大概为40ms。ComponentDescriptionRel-8Rel-8Rel-8

Minimum(ms)PRACHinsubframe#2/#3/#7/#8Average[ms]PRACHinsubframe#1/#6

Msg1insubframe#2or#7(probability=0.8)Msg1insubframe#3or#8(probability=0.2)Msg1insubframe#1or#61AveragedelayduetoRACHschedulingperiod20.52.52RACHPreamble1113-4PreambledetectionandtransmissionofRAresponse(TimebetweentheendRACHtransmissionandUE’sreceptionofschedulinggrantandtimingadjustment)+delayfornearestDLsubframe3355UEProcessingDelay(decodingofschedulinggrant,timingalignmentandC-RNTIassignment+L1encodingofRRCConnectionRequest)+delayfornearestULsubframe6556TransmissionofRRCConnectionRequest1117ProcessingdelayineNB(L2andRRC)+delayfornearestDLsubframe6668TransmissionofRRCConnectionSet-up(andULgrant)1119ProcessingdelayintheUE(L2andRRC)+delayfornearestULsubframe17171710TransmissionofRRCConnectionSet-upcomplete(inclingNASServiceRequest)11111ProcessingdelayineNB(Uu–>S1-C)44412S1-CTransferdelayT_S1T_S1T_S113MMEProcessingDelay(includingUEcontextretrievalof10ms)15151514S1-CTransferdelayT_S1T_S1T_S115ProcessingdelayineNB(S1-C–>Uu)44416TransmissionofRRCSecurityModeCommandandConnectionReconfiguration(+TTIalignment)17ProcessingdelayinUE(L2andRRC)202020

Totaldelay[ms]83.180.684.6

AveragedTotaldelay[ms](consideringtheprobabilityofMsg1transmissionlocation)83.1*0.8+80.6*0.2=82.6N/AeNB上下文建立和SIP空口承载建立时延（主叫侧）UE建立RRC连接后，eNB发送初始UE消息到MME，MME下发初始上下文建立消息到eNB，eNB建立UE上下文并建立对应无线承载。此部分时延包含：S1AP消息在S1接口的往返传递时延15ms，RB重配命令传递时延2msUE的处理时延20msMME的处理时延15mseNB的处理时延8ms此部分时延共计60ms。PoC信令传递以及处理时延(EUTRAN+CN)空口承载建立完成后，UE发送PoC信令INVITE消息到网络，SIPCORE和PoCServer对PoC信令进行处理并转发到被叫端，被叫端响应后，SIPCORE和PoCserver发送PoC响应信令消息到主叫用户，此部分时延包含：PoC信令和响应信令在空口传递时延为5msPoC信令和响应信令在eNB和PGW之间的传递时延时延为50msPoC信令和响应信令在SIPCORE和PoCServer之间传递的时延为150msPoC信令在SIPCORE和PoCServer的处理时延为150msPoC信令和响应信令在被叫端PGW和eNB之间的传递时延为50ms被叫UE寻呼时延DRX寻呼周期系数K值决定了DRX周期长度，K值越大，DRX周期就越长，UE功耗会降低，但是也带来了UE寻呼周期变长。如果K值过小，寻呼周期变小，UE处理寻呼开销和功耗都会增加。这里以寻呼周期为640ms秒为例，平均寻呼时延为320ms左右。UE从空闲态转为连接态的时延（被叫侧）被叫UE收到寻呼消息转为连接态的流程与7.1.1类似，需要40ms时延。eNB上下文建立和SIP空口承载建立时延（被叫侧）被叫侧eNB上下文建立和SIP空口承载建立时延与7.1.2类似，需要60ms时延。UE处理时延主叫和被叫UE按键处理以及应用层PoC信令处理时延为100ms未优化话权申请时延用户加入集群会话后，从主叫用户按键请求话权，到接收到网络下发的话权授权消息为止，之间的时间间隔被定义为话权申请时延。与集群业务建立时延类似，此部分时延也包含主被叫用户从空闲态转移到连接态并建立空口承载时延，PoC信令传递以及处理时延，被叫用户寻呼时延和主被叫终端处理时延。与集群业务建立的不同在于PoC信令和SIPCore/PoCServer的处理不同，总的话权申请时延时延大约为900～1000ms。时延优化从以上的时延分析可以看出，集群业务建立时延和话权申请时延主要由PoC信令传递/处理和寻呼被叫用户的时延组成。LTE的空口设计已经将UE从空闲态转移到连接态的时延减少到40ms，与UMTS相比已经不是PoC时延的主要组成部分。寻呼优化按照现有寻呼机制，可以通过减少寻呼周期的方法来降低寻呼时延：集群业务终端可以上报特定的DRX给网络，网络根据此特定的DRX来寻呼UE减少时延。此方法重用现有机制，对标准改动较小，只需要上报一个集群业务相关的DRX。用户的签约信息中包含特定的DRX值，在寻呼UE时，MME使用此特定的DRX来减少寻呼时延。另一种方案是让网络感知集群用户，一旦集群UE附着到网络则永远保持连接态：UE上报集群标识给网络，eNB不主动发起RRC连接的释放用户的签约信息中包含集群标识，MME在UE附着流程中获得此签约数据并将集群标识传递给eNB，eNB不主动发起RRC连接的释放采用此种方案，集群UE附着到网络后永远保持连接态，被叫时不存在寻呼的流程，时延性能大大提升。PoC信令传递/处理时延优化第6.4节的时延分析基于复杂的网络拓扑和标准的PoC信令交互。在简单的网络拓扑，例如主被叫用户都在相同的SIPCore和PoCserver的情况下，并且SIPCore和PoCServer合一的情况下，传递和处理时延将大大优化。PoC信令本身的优化在方案中没有细化，需要进一步研究和细化。优化后集群业务建立时延采用UE附着到网络一直保持连接态的方案，被叫用户不存在寻呼和从空闲态转移到连接态的过程，可以减少420ms的时延（320ms＋100ms）。PoC信令传递和处理时延可以优化到200ms。优化后的集群业务建立时延主要由以下组成，共计400ms：主叫用户从空闲态转移到连接态并建立上下文和无线承载的时延100msPoC信令传递/处理时延200ms主被叫终端的按键和PoC信令响应时延100msPoC信令本身的优化在方案中没有细化，需要进一步研究和细化。此部分PoC信令传递/处理时延优化分析基于简单的网络拓扑假设，PoC信令本身优化带来的时延减少还没有涉及，需要后续研究。优化后的话权申请时延采用UE附着到网络一直保持连接态的方案，被叫用户不存在寻呼和状态转移的过程，主叫用户同样不存在状态转移的时间。此时时延主要由PoC信令传递和在UE/网络的处理时延，共计300ms。方案比较终端耗电问题分析处于RRC_CONNECTED状态UE的主要行为如下：监控寻呼信道和广播消息系统信息块类型1（SIB1），检测系统消息的改变。监控与共享数据信道相关的控制信道，确定是否有自己的数据调度；提供信道质量和反馈信息；执行邻小区测量和测量上报；获取系统消息。处于RRC_IDLE状态UE的主要行为如下：监控寻呼信道，检测呼叫以及系统消息的改变邻小区测量和小区选择/重选；获取系统消息。比较两种状态下的UE，其中处于RRC_CONNECTED状态主要耗电的工作在于信道质量和反馈以及监控物理下行控制信道（PDCCH）。在LTE标准中，eNB可以通过媒体接入层（MAC）配置UE在特定的DRX来进行功率的节省。在RRC_CONNECTED期间，配置了DRX功能的UE，在激活期监听PDCCH，在静默期可以不监听PDCCH信道也不需要进行信道质量反馈。通过这样的方式，UE可以达到在RRC_IDLE下DRX中相似的功率消耗。较低的时延是集群系统重要的性能指标，而对应的降低被叫集群用户的接入时延是无法回避的问题。新的集群寻呼信道的引入，同样需要UE在配置的较短时间间隔内监听集群寻呼信道而带来UE耗电的增加。本方案将UE置于连接态，通过设定连接态的DRX，同样可以避免静默期的功率消耗来增加集群UE的待机时间。系统容量分析UE处于连接态导致的系统容量问题，属于LTE的系统容量问题，需要在方案比较时，考虑系统容量方面的分析。方案三系统架构系统组成基于EMBMSOverTD-LTE技术的宽带数字集群通信系统的网络结构如REF_Ref274646269\h图71所示。图STYLEREF1\s7SEQ图\*ARABIC\s11网络结构图应用侧包括集群应用服务器和集群网关，完成集群业务的调度功能，它是PDN网关的入口。集群应用服务器按照此架构，可以根据需要，与多种集群应用服务器连接提供集群业务，例如：基于PoC的集群应用服务器（方案二）基于Gota的集群应用服务器其他类型的集群应用服务器（方案一）本系统以PoC集群应用服务器为例说明，PoC与IMS之间通过自定义接口完成相关信令交互。。网络侧在支持现有功能（包括eMBMS）的基础上，增加集群业务的功能，即：存储和管理集群用户签约信息和集群业务的全网组呼。PDN网关（PDNGW）支持现有功能，并支持与多种集群应用服务器的接口，以根据不同需求支持各种集群业务。对于集群业务，PDN-GW可以根据单呼（普通承载）还是组呼（每个集群业务组，都分配一个TMGI标识），选择下行数据分发到S/PGW还是BM-SC，即：选择单播模式还是多播模式（MBSFN模式）。BM-SC现有功能。并支持集群业务，其建立的MBMSBearerContext包括：MBMSBearerContextinBM-SCParameterDescriptionTMGITemporaryMobileGroupIdentityallocatedtotheMBMSbearerservice.QoSQualityofServicerequiredfortheMBMSbearerservice.MBMSServiceAreaAreaoverwhichtheMBMSbearerservicehastobedistributed.ListofdownstreamnodesMBMS-GWIDMBMSHCindicatorFlagsetbyBM-SCifitisusingcompressedheaderforthepayload.注：集群业务所配置MBMSBearerContext是普通MBMS业务的一部分，也就是与其他集群无关的参数无意义。MBMSGW现有功能。并支持集群业务，其建立的MBMSBearerContext包括：MBMSBearerContextinMBMSGWParameterDescriptionTMGITemporaryMobileGroupIdentityallocatedtotheMBMSbearerservice.C-TEIDCommonTunnelEndpointIdentifierofMBMSGWforuserplaneQoSQualityofServicerequiredfortheMBMSbearerservice.MBMSServiceAreaAreaoverwhichtheMBMSbearerservicehastobedistributed.ListofdownstreamnodesListofdownstreamnodesthathaverequestedtheMBMSbearerserviceandtowhichnotifications（静态区域时候无此参数）IPmulticastandSourceaddressfordistributionIPaddressesidentifyingtheSSMchannelusedforuserplanedistributiononthebackbonenetwork注：集群业务所配置MBMSBearerContext是普通MBMS业务的一部分，也就是与其他集群无关的参数无意义。注：MBMSServiceArea由BM-SC配置。静态配置MBSFNarea时候，即：集群业务的分发区域（MBSFNarea,涉及的eNB，也就是“Listofdownstreamnodes”固定配置）固定；而动态配置时候，即：集群业务的分发区域（涉及的eNB），不配置“Listofdownstreamnodes”，是根据集群用户附着时候的信息而由MME动态形成。MME支持现有功能，同时增加支持集群功能的模块。其建立的MBMSBearerContext包括：MBMSBearerContextinMMEParameterDescriptionMBMSGWTEID-CTunnelEndpointIdentifierofMBMSGWforcontrolplane.TMGITemporaryMobileGroupIdentityallocatedtotheMBMSbearerservice.MBMSGWIPAddressforControlPlaneinuseTheIPaddressoftheMBMSGWusedforthecontrolplane.MBMSGWIPAddressforUserPlaneinuseTheIPaddressoftheMBMSGWusedfortheuserplane.QoSQualityofServicerequiredfortheMBMSbearerservice.MBMSServiceAreaAreaoverwhichtheMBMSbearerservicehastobedistributed.ListofdownstreamnodesListofdownstreamnodesthathaverequestedtheMBMSbearerserviceandtowhichnotificationsIPmulticastandSourceaddressfordistributionIPaddressesidentifyingtheSSMchannelusedforuserplanedistributiononthebackbonenetworkMBMSHCindicatorFlagsetbyBM-SCifitisusingcompressedheaderforthepayload.注：集群业务所配置MBMSBearerContext是普通MBMS业务的一部分，也就是与其他集群无关的参数无意义。该新增支持集群业务的模块实现：存储集群用户终端的相关信息，负责向HSS获取集群用户终端的签约信息等。UE附着/去附着时候，HSS和MME上会存储该UE的位置信息（属于哪个eNB）（即：Listofdownstreamnodes，也就是TNLinformation），以及用于该UE今后群呼用的TMGIID。即：HSS和MME中存储：{TMGI1，TNLinformation，UElist}；{TMGI2，TNLinformation，UElist}，….{TMGIn，TNLinformation，UElist}当静态MBSFNarea（即：集群业务的分发节点eNB固定配置），“TNLinformation”由上级网元MBMS-GW配置。当动态MBSFNarea（即：集群业务的分发节点eNB根据UE附着/去附着后重配置），“TNLinformation”由HSS/MME配置。HSS支持现有功能，同时增加支持集群功能的模块。该新增模块实现：用于存储和管理与集群业务相关的组用户信息。通过与MME的信息交互，与MME上集群的信息相同。MCE支持现有功能，同时增加支持集群功能。在第一阶段，MCE不需要做修改就可以支持集群业务，在第二阶段，对于支持的集群业务，可以进一步地在建立集群业务时，负责为集群用户提供TRNTI（组呼的RNTI），用于多个DL-SCH上发送集群业务；也就是，在第一阶段，MCE仅支持在空口采用MBSFN传输；而在第二阶段，MCE可以支持在空口采用unicast传输。S-GW现有功能。eNB现有功能。对于集群的组呼；第一阶段采用MBSFN传输，第二阶段了可以采用unicast传输，即可以优化（如：方案一）。无线侧Uu接口的改进，详见方案一，用于减少时延和提高频谱效率。增加集群业务的传输信息和逻辑信息等。接口与信令对于3GPP已有接口，在支持现有功能的基础上，增加支持集群优化的功能。这些优化包括：Uu接口可以优化（详见方案一），用于减少时延和提高频谱效率。增加集群业务的传输信息和逻辑信息等。M2接口MBMSSchedulingInformation集群业务有两种无线资源的分配模式：（1）多小区发送，由MCE进行时频资源分配，现有3GPP规范即可支持。（2）如果是单小区发送，则由eNB进行时频资源分配，此时需要修改3GPP修改规范。例如可以采用方案一。下面是在M2、M3接口几个主要的消息。MBMSSessionStartrequestDirection:MCEeNB.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionCriticalityAssignedCriticalityMessageTypeMYESrejectMCEMBMSM2APIDMYESrejectTMGIMHYPERLINKYESrejectMBMSSessionIdentityO集群业务不使用该IEYESignoreMBMSServiceAreaMHYPERLINKYESrejectTNLInformationMYESreject>IPMulticastAddressMIPAddress->IPSourceAddressMIPAddress->GTPDLTEIDMGTP-TEID

-MBMSSESSIONUPDATEREQUESTDirection:MCEeNB.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionCriticalityAssignedCriticalityMessageTypeMYESrejectMCEMBMSM2APIDMYESrejecteNBMBMSM2APIDMYESrejectTMGIMYESrejectMBMSSessionIdentityO集群业务不使用该IEYESignoreMBMSServiceAreaOYESignoreTNLInformationOYESreject>IPMulticastAddressM->IPSourceAddressMIPAddress->GTPDLTEIDMGTP-TEID

-MBMSSCHEDULINGINFORMATIONDirection:MCEeNB.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionCriticalityAssignedCriticalityMessageTypeMYESrejectMCCHUpdateTimeMHYPERLINK9YESrejectMBSFNAreaConfigurationListMYESreject>MBSFNAreaConfigurationItemIEs1to<maxnoofMBSFNareas>第二阶段，集群组呼可以不配多播资源，而由eNBs配置单播资源。EACHreject>>PMCHConfigurationListMYESreject>>>PMCHConfigurationItemIEs0to<maxnoofPMCHsperMBSFNarea>EACHreject>>>>PMCHConfigurationMHYPERLINK->>>>MBMSSessionListperPMCHM->>SubframesConfigurationListMYESreject>>>SubframesConfigurationItemIEs1to<maxnoofMBSFNallocations>EACHreject>>>>MBSFNSubframeConfigurationMHYPERLINK7->>CommonSubframeAllocationPeriodM8YESreject>>MBSFNAreaIDM4YESrejectM3接口MBMSSESSIONSTARTREQUESTIE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionCriticalityAssignedCriticalityMessageTypeMYESrejectMMEMBMSM3APIDM9.2.YESrejectTMGIM9.2.YESrejectMBMSSessionIdentityO9.2.集群业务不使用该IEYESignoreMBMSE-RABQoSparametersM9.2.YESrejectMBMSSessionDurationM9.2.YESrejectMBMSServiceAreaM9.2.YESrejectMinimumTimetoMBMSDataTransferMYESrejectTNLInformationMYESreject>IPMulticastAddressM9.2.->IPSourceAddressM9.2.->GTPDLTEIDMGTPTEID9.2.-MBMSSESSIONUPDATEREQUESTDirection:MMEMCE.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionCriticalityAssignedCriticalityMessageTypeMYESrejectMMEMBMSM3APIDM9.2.YESrejectMCEMBMSM3APIDM9.2.YESrejectTMGIM9.2.YESrejectMBMSSessionIdentityO9.2.集群业务不使用该IEYESignoreMBMSE-RABQoSparametersM9.2.YESrejectMBMSSessionDurationM9.2.YESrejectMBMSServiceAreaO9.2.YESignoreMinimumTimetoMBMSDataTransferMYESrejectTNLInformationOYESignore>IPMulticastAddressM9.2.->IPSourceAddressMIPAddress9.2.->GTPDLTEIDMGTPTEID9.2.-业务流程附着对于集群终端，开机后先附着到网络上，流程如下图所示：图STYLEREF1\s7SEQ图\*ARABIC\s12附着过程1~5、集群终端进行随机接入和RRC链接建立。6~10、MME收到初始化请求消息（包括附着请求消息），则MME向HSS发送认证数据请求消息，向HSS请求认证向量。HSS计算认证向量(通过IMSI等生成)，同时从数据库中获得该集群终端的所归属的TMGI-ID。注：如果集群终端加入/退出一个集群业务组（TMGI），则根据该UE所在eNB新建/删除或更新“Listofdownstreamnodes”（eNB的集合）信息，在HSS和MME同步地存储：{TMGIID，MBMSservicearea，“Listofdownstreamnodes”，UE列表},该信息并通过认证数据响应携带给MME，MME进行保存。其用途是在动态分发时候建议为一个集群业务生成一个分发树。11~12、集群终端和网络进行相互认证。13~14、认证通过后，创建承载。15、承载创建成功后，MME向eNB/MCE发送初始化上下文建立请求消息。16~19、RB建立完成，初始上下文建立完成，附着完成。注：一个集群组用一个TMGIID标识，HSS中存储的TMGIID是与集群终端的IMSI所对应。第一阶段暂时只考虑一个集群终端归属与一个集群组的情况（一个IMSI仅属于一个TMGI），第二阶段再考虑一个集群终端归属与多个集群组的情况。点对点业务流程假设集群终端A需要和集群终端B进行语音对话，对这种点对点的业务，使用PoC应用服务即可实现。流程如下图所示：图STYLEREF1\s7SEQ图\*ARABIC\s13点对点业务流程1~5、集群终端A处于空闲状态，集群终端组B处于空闲状态，集群终端A向集群终端组B发起呼叫业务时，集群终端A先进行无线承载的建立，进行随机接入并进行RRC连接建立。6、集群终端A通过初始UE消息，其中包含服务请求，服务请求类型标识为点对点集群呼叫。7、集群终端A与SCSCF和HSS交互，完成集群终端A与IMS域的安全认证。8~9、进行NAS安全机制的协商。10~13、MME执行初始化上下文建立过程，在eNB内产生EPS承载和终端上下文，并且在空口进行无线资源的建立。14~15、MME为服务网关和PDN-GW更新相关承载，其中信息包含点对点承载类型，PDN-GW在后续中使用该信息对数据流向进行区分。16~18、集群终端A则与Poc服务器进行SIP应用层信令的交互后，则建立端到端的SIP会话，这时PoC服务器向集群终端A发起通话权许可的消息，同时向集群终端组B发送通话权占用的消息，然后就可以进行语音通话的业务。19~21、PoC服务器收到集群终端A的语音数据后，则向PDN-GW发送语音数据，PDN-GW判定该语音数据所在的承载为点对点类型，则将该数据发送至S-GW，后续则按照正常的流程进行数据的发送。另外，MME在寻呼集群终端B，MME发送寻呼消息到eNB，集群终端B收到寻呼消息后，则发起随机接入和RRC连接建立流程。（与集群终端A的流程相同）。从上述流程看出，对于集群点对点的业务，使用LTE的现有网络架构和消息流程，并用IMS+PoC来实现，做到与现有LTE系统的兼容。点对多点业务流程假设集群终端A需要和集群终端组B进行语音对话，对这种点对多点的业务，采用PoC+MBMS的方法来实现，流程如下图所示：图STYLEREF1\s7SEQ图\*ARABIC\s14点对多点业务流程1~5、集群终端A处于空闲状态，集群终端组B，其中集群终端组B包括多个集群终端。处于空闲状态，集群终端A向集群终端组B发起呼叫业务时，集群终端A先进行无线承载的建立，进行随