，则顺从性实体可以发送请求的第二轮。还允许请求的附加轮。这些请求的范围可以彼此不同。例如，第一请求可以被狭窄地导向到一个或几个应用，而第二或随后的请求可以被导向到许多或所有应用。附加地，可能地，集体顺从性指示包括可以通过遵照具体请求实现顺从性分数提升的相对量的指示。在该情况下，第二轮请求然后可以潜在地传达较大的顺从性分数提升。用户还可以因此被传达到响应于第1顺从性请求而拒绝遵照的某些相同app。
[0052]顺从性实体还可以向应用报告关于它们当前的顺从性分数。例如，顺从性实体可以向应用发送分数。而且，应用可以结合起来同意基于将改进集体内的所有应用的体验的某些最佳实践或约定的规则、在相同小区中跨应用来协作。不在集体内的应用可以因此是较少有竞争性的。
[0053]例如，当集体中的较大数量的应用被预期或当前遭受较低的吞吐量而满足相同小区中的较高的比特率服务时，则集体内的其他应用可以预先自动地执行较大的预取以便减少拥塞。其他应用在拥塞的小区中时还可以执行其他相对低优先级的0ΤΤ服务的较大节流。更进一步地，某些应用可以执行导航路线修改。
[0054]在某些实施例中，由单个UE内的集体监视功能进行的跨应用的集体顺从性计分也是可能的。通过在每应用基础上使设备0S维持关于拥塞避免最佳实践的度量，顺从性实体可以鼓励UE设备上的每个应用的较大的资源效率。例如，提供更好的拥塞避免最佳实践依附(adherence)的应用可以接收分配给UE的带宽的、比设备上的其他应用大的部分，可选地具有比设备上的其他应用小的延迟。
[0055]鼓励协作行为的第一示例可以是在预期第二应用将需要在即将到来的吞吐量受限小区或环境中执行实时服务时鼓励由设备上的第一应用进行的较大的预取。
[0056]该情况中的益处是当第二应用正在同时执行较高比特率实时服务时可以存在对需要获取业务的第一应用的更主动的(proactive)避免。正常地，第一应用将不需要同样多地预取，但因为第二应用的预期的需要和期望的相应的网络吞吐量，所以可以更适合针对第一应用预取以便减小两个应用将需要同时取回的可能性。
[0057]鼓励协作行为的第二示例可以是当设备上的第二应用需要在即将到来的吞吐量受限小区或环境中执行实时服务时鼓励由该设备上的第一应用进行的较大的压缩。例如，这可以由对分配给UE的RF资源的部分执行节流的UE设备0S实现，其被用来相对于第二应用调度来自第一应用的业务。
[0058]某些实施例可以通过跨相同小区中的不同的设备或应用的集体监视功能，诸如通过应用仓库和/或UE操作系统，来提供跨应用的集体顺从性计分，所述应用/设备在集体中。在其中集体自己的设备中的更多将很可能受益的情况中，针对其自己的设备减少拥塞可以在集体的自身利益中。
[0059]鼓励协作行为的第三示例可以是鼓励由被预期不久在小区中的集体的设备进行的较大的预取，所述小区将完全挤满集体的设备中的任何其他设备。如果存在被期望在挤满了相同操作系统的用户的小区中的单个集体成员设备，并且集体成员用户不被期望需要任何高比特率、无线服务该小区，则对于该单个集体成员而言执行预取是较不重要的。
[0060]某些实施例可以涉及基于集体中的其他应用或用户的通信需求来修改地图应用中的导航。导航应用的用户，用户X，可以正在生成媒体比特率业务某个适度的量，并且可能将驾驶通过挤满了相同操作系统的用户的小区，所述用户是不满意的或需要非常高的比特率或低延迟。
[0061]正常地，用户X将不需要修改路线，因为在该拥塞的小区中预期的吞吐量不足以影响用户X的自己的无线体验。然而，在某些实施例中，因为选择路线可以极大地影响在该小区中的相同操作系统的显著大量的其他用户，所以导航应用可以自动地修改用户的X的路线。
[0062]相对地，在某些实施例中，如果拥塞的小区仅或主要被填充有其他操作系统的不满意的用户或被填充有相同操作系统的低优先级的用户，则导航应用用户不需要修改路线来避免小区。
[0063]因此，可以存在针对集体中的应用的附加值，因为应用和开发者可以采取消费者基础和做正确的事情而不适配他们的业务以便改进非协作应用的消费者体验的更全局的观点。
[0064]图1图示了根据某些实施例的方法的流程图。如图1中示出的那样，方法可以包括在110处初始化针对每个应用(App )的客户端分数的默认值。方法还可以包括在120处等待来自任何应用j的S0S或求助请求。当从应用j接收这样的请求时，可以在130处做出关于应用j是否具有高于阈值的点分数(points score)的确定。如果否，则等待可以在120处继续。如果点确实超过阈值，则在140处请求可以被转发到应用集体中的应用i。该应用可以在与正在请求帮助的应用j的实例相同的用户设备中或相同小区中。
[0065]系统可以在150处监视应用i对请求的顺从性。可以在160处做出关于应用i是否已经被遵照的确定。如果这样，可以在170处使针对应用i的顺从性分数增加。否则，在180处可以使顺从性分数减少。在任一情况下，过程可以返回到120处等待。
[0066]图2图示了根据某些实施例的信号流。如在图2中示出的那样，在210处应用(App)3可以向UE OS或另一顺从性管理实体发送SOS请求。在220处，UE OS或其他顺从性管理实体可以确定应用3具有大于预定阈值的顺从性点分数。因此，在230处，UE 0S或其他顺从性管理实体可以将S0S中继到应用2，并且在240处UE 0S或其他顺从性管理实体可以将S0S中继到应用1。这些可以被单独地发送或作为广播消息发送。
[0067]在250处，UE0S或其他顺从性管理实体可以监视顺从性和/或等待并且接收来自应用1的响应。同样地，在260处，UE 0S或其他顺从性管理实体可以监视顺从性和/或等待并且接收来自应用2的响应。然后，在270处，针对每个应用——在该情况中是应用1和应用2一一UE 0S或其他顺从性管理实体可以在270处确定应用是否是顺从的。如果应用是不顺从的，则UE 0S或其他顺从性管理实体可以在280处使顺从性分数减少，或者如果应用是顺从的，则UE 0S或其他顺从性管理实体可以在290处使顺从性分数增加。
[0068]图3图示了根据某些实施例的方法。如在图3中示出的那样，方法可以包括在310处监督应用的组。方法可以由应用的组驻留于其上的用户设备执行。替代地，方法可以由网络元素或对等节点执行，如上文提及的那样。例如，方法可以由远离应用的组驻留于其上的用户设备的服务器上的集体顺从性实体来执行。
[0069]方法还可以包括在320处监视组的多个应用中的每个的至少一个自我优化。方法可以进一步包括在330处基于自我优化是否使与相应的应用不同的组受益来向多个应用中的至少一个发送请求。
[0070]请求可以被配置成指示减少不必要的业务的量的时间、减少不必要的业务的量的位置或预取的百分比深度中的至少一个。例如，请求可以是或包括导航以避免地理区域的请求。
[0071]方法可以附加地包括在340处接收关于应用的组的第一应用的、针对第一应用的资源需求未被满足的指示。而且，方法可以包括在342处向组的至少一个应用发送指令以基于该指示适配。这可以是或涉及在330处发送请求。该指令可以是非强制的并且可以被称作请求。
[0072]换言之，发送可以涉及基于请求和监视的自我优化是否使与相应的应用不同的组受益而向多个应用中的至少一个发送自我优化请求。因此，因为请求可以基于自我优化是否使与相应的应用不同的组受益。
[0073]请求可以指示顺从性分数益处/模型并且可以基于自我优化是否使与相应的应用不同的组受益。而且，可以以基于请求的和监视的自我优化是否使与相应的应用不同的组受益的方式来完成请求的发送。例如，可以代表已知是顺从的App发送一般请求或更多请求。替代地，方法可以涉及将一般请求或更多请求发送到还未被示出为大量顺从性，并且因此可能需要示出或获得顺从性评级(rating)的App。也允许其他变型。
[0074]可以在0ΤΤ层处执行请求的消息收发，如与通过PCRF信令或无线电信令传输相反。
[0075]更进一步地，方法可以包括在350处监视关于指令的多个应用中的每个的顺从性。
[0076]指令可以进一步基于第一应用的顺从性分数。顺从性分数可以与应用之中的协作行为相关。
[0077]指令可以关于超过预定阈值的第一