51学通信技术论坛 › 标签 › 用户

标签: 用户

相关帖子	版块	作者	回复/查看	最后发表

IMS网络中的用户标识都有哪些？	8.1 IMS技术入门	admin 2013-3-3	6 7845	xrytiancai 2018-7-17 11:17:54
HSS中未签约STN-SR，导致用户注册失败	8.3.1 现网案例	admin 2016-4-16	0 3876	admin 2016-4-16 15:23:08
中兴HSS APN签约错误导致VoLTE用户无法注册到IMS的故障案例	7.5.1 现网案例	admin 2016-4-16	0 3350	admin 2016-4-16 15:18:35
VOLTE用户注册的透明数据传送问题案例	8.3.1 现网案例	admin 2016-4-16	0 4432	admin 2016-4-16 15:05:58
5.2.4 初始附着与切换附着 5.2.5 静态IP地址与动态IP地址 5.2.6 NAS安全性	2.1.5 3GPP系统架构演进(SAE)原理与设计:姜怡华等	爱卫生 2012-11-4	1 5126	cool_pine 2014-2-17 22:49:02
一种无线劣质小区定位的新方法	6.2.2 GPRS分组域核心网工程与现网	爱卫生 2013-2-17	4 5215	lihongya66 2013-12-7 17:27:00
3G漫游用户SGSN附着问题的分析与处理	6.2.1 GPRS分组域核心网故障排查	admin 2013-6-12	0 3058	admin 2013-6-12 16:51:16
当UE丢失无线侧覆盖的防止对用户多计费的防护功能：Overcharging Protection on Loss	6.2.3 策略控制与计费PCC	admin 2013-4-12	4 4060	hycl5410 2013-4-24 06:11:36
EPC网络中的ME id检查过程	2.2.2 EPC相关规范	admin 2013-4-12	0 3531	admin 2013-4-12 14:58:58
EPC网络中的用户数据管理	2.2.2 EPC相关规范	admin 2013-4-12	0 3388	admin 2013-4-12 14:21:44
EPC网络中用户在ECM-IDLE状态时的可达性管理	2.2.2 EPC相关规范	admin 2013-4-7	0 3409	admin 2013-4-7 22:39:09
GPRS家园用户行为分析之百度关键字排行	1.2 论坛公告	admin 2013-3-27	0 4235	admin 2013-3-27 19:47:11
蜂窝通信系统中的频谱	4.1 通信百科（术语及名词解释）	admin 2013-2-3	0 3959	admin 2013-2-3 15:02:15
移动互联网用户行为分析系统技术架构浅析	9.2 互联网业务运营与营销	爱卫生 2013-1-21	0 5364	爱卫生 2013-1-21 23:51:04
GSM复制卡问题的分析及信令解决方法	6.1.2 GPRS分组域核心网协议与信令流程	爱卫生 2013-1-20	0 3976	爱卫生 2013-1-20 22:55:22
限制用户超地域使用GPRS业务的研究及测试	6.2.5 GPRS分组域核心网高级话题	爱卫生 2012-12-12	2 4738	dannyhu 2012-12-13 23:09:31
6.6Iur与Iub接口的用户面帧协议	2.1.4 WCDMA关键技术详解:姜波	爱卫生 2012-12-9	0 3994	爱卫生 2012-12-9 14:03:02
6.3 Iu接口（开头介绍）	2.1.4 WCDMA关键技术详解:姜波	爱卫生 2012-12-8	0 4152	爱卫生 2012-12-8 17:52:52
2.3 用户标识以及网络的区域划分	2.1.4 WCDMA关键技术详解:姜波	爱卫生 2012-12-1	1 4687	爱卫生 2012-12-1 15:46:48
1.1 移动通信发展历史	2.1.4 WCDMA关键技术详解:姜波	爱卫生 2012-11-27	0 3564	爱卫生 2012-11-27 21:47:01

更多...

相关日志

分享专载小琨琨的爸爸博文-VoLTE技术中的会话持续性-eSRVCC: wjy 2016-3-4 15:05; 目录 eSRVCC方案对于SRVCC方案的改进及标准信令面、媒体面在切换前后的路径 eSRVCC业务流程一、用户注册流程：STN-SR，ATU-STI，C-MSISDN 二、用户呼叫流程：正常的IMS呼叫，但必须控制锚定媒体到ATGW 三、eSRVCC切换流程：STN-SR，ATU-STI，C-MSISDN 其它技术点 IMS-HSS新增数据项控制非SRVCC用户呼叫不需经过ATCF的方法缓存8秒的过程 eSRVCC是否兼容SRVCC eSRVCC的缺点 ======== eSRVCC方案对于SRVCC方案的改进及标准 3GPP TR 23.856 Single Radio Voice Call Continuity (SRVCC) enhancements; Stage 2 介绍了各种eSRVCC方案的备选方案。介绍了业务流程。 3GPP TS 23.237 V12.0.0 (2012-06) 的5.2.2Architecture when using ATCF enhancements 明确了本文的eSRVCC方案介绍了业务流程。 3GPP TS 24.237 V11.4.0 (2012-09) P Multimedia Subsystem (IMS) Service Continuity; Stage 3 介绍了流程与信令扩展的细节。思路：引入接入侧媒体锚点，减少 Remote Update 的信令传输时间。 eSRVCC可视为SRVCC的升级版本（实际上 SRVCC方案与eSRVCC方案可以在一个运营商网络中共存）。与SRVCC相比，新增ATCF/ATGW网元，SCC-AS功能有增强，HSS透明数据有新增。其它网元功能不变（比如MME、eMSC、UE) 信令面、媒体面在切换前后的路径切换的信令面变化，参见：切换前后的信令均经过了ATCF。媒体面的切换路径参见：切换前后的媒体均经过了ATGW。 ATCF/ATGW:信令锚定点，媒体锚定点从信令面来说，多了一个网元，多了一些信令传递。但由此带来的时延不大。关键是IMS 远端update过程在大多数情况下可以不做。从媒体面来说，多了一个网元。但由于切换前后的媒体均锚定到ATGW。对远端来说看到的SDP是ATGW产生。当ATGW SDP不变时，可以不需要Update remote end。切换时延将大大减少。 ATCF可与P-CSCF或SBC合设。大部分呼叫是不需要update remote end的。但如果切换后，媒体类型（如audio、video）发生变化（比如2G CS域只支持audio了），或ATGW无法完成Transcoding，或ATCF发现用户有多路呼叫，则需更新远端媒体。此时ATCF发起Invite(ATU-STI)给SCC-AS。SCC-AS会关联到远端用户，并更新远端媒体。同时bye掉前面建立的呼叫leg（也是这个ATCF发过来的) eSRVCC中，媒体的锚定在ATGW，信令的锚定由ATCF与SCC-AS共同完成（如上所述，呼叫、切换产生的新呼叫都会发到SCC-AS）。当用户有多路呼叫时，UE切换时只发起一路呼叫的切换，即MSC只会发起一路呼叫到ATCF。SCC-AS发现用户有多路呼叫时，会发 Refer消息给ATCF，再转发给MSC，由MSC在CS域内发起第二路呼叫。 eSRVCC业务流程一、用户注册流程：STN-SR，ATU-STI，C-MSISDN 用户在LTE侧发起注册，呼叫在LTE承载上，经过PGW发到互联网上IMS域：P-CSCF/A-SBC-ATCF-S-CSCF-SCC AS。注册时，ATCF分配dynamic STN-SR，在注册消息中发给SCC AS， SCC AS修改IMS-HSS中用户数据，HSS将修改的数据下插到MME中，切换时带给eMSC。注：这个过程中：SCC AS、IMS-HSS、MME的操作与SRVCC方案一样。区别只是SRVCC中，STN-SR是SCC AS产生。而eSRVCC中，STN-SR是由ATCF产生。原因是：SRVCC中，MSC直接发切换请求给SCC AS(带STN-SR)，而eSRVCC中，MSC发切换请求给ATCF（带STN-SR) 。对于SCC-AS来说，由于同时作为ICS、SRVCC、eSRVCC方案的网元，当收到呼叫时，需要识别当前所承担的网元角色。在SCC-AS收到S-CSCF发来的第三方注册请求消息中，携带Feature-Caps头部（由ATCF插入），如SCC-AS发现Feature-Caps中存在+g.3gpp.atcf参数，则认为是eSRVCC用户的注册。对于eSRVCC用户的注册，SCC AS会把+g.3gpp.atcf信息更新到IMS HSS，并从IMS HSS下载到特定的用户数据（非透明数据，见“IMS-HSS新增数据项”一节）。对于eSRVCC用户的注册，SCC AS在注册成功后，向终端发送MESSAGE，MESSAGE的消息体中含有ATU-STI与C-MSISDN(从HSS下载得到，属于签约放号数据)。ATU-STI由SCC AS自己产生，用来识别呼入请求是否是eSRVCC用户发来的切换请求。 ATCF在注册消息的Feature-Caps头部携带了多个信息： 1, +g.3gpp.atcf填写STN-SR，用于向SCC AS、HSS、MSC Server更新用户的SRVCC地址信息。 2，+g.3gpp.atcf-mgmt= "sip:actf.visited2.net"用于SCC AS向ATCF发送message消息时的request URI。 STN-SR实际上分两种：STN-SR、vSTN-SR。见SRVCC方案。注：3GPP TS 24.237 V11.4.0 (2012-09) Table A.3.3-1: SIP REGISTER request (UE to P-CSCF) REGISTER sip:home1.net SIP/2.0 Via: SIP/2.0/UDP ;comp=sigcomp;branch=z9hG4bKnasiuen8 Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 From: sip:user1_public1@home1.net;tag=2hiue To: sip:user1_public1@home1.net Contact: sip: ;comp=sigcomp;+sip.instance="urn:gsma:imei:90420156-025763-0;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel" Call-ID: E05133BD26DD Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response="" Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678 Require: sec-agree Proxy-Require: sec-agree CSeq: 1 REGISTER Supported: path, gruu Content-Length: 0 Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF) REGISTER sip:home1.net SIP/2.0 Feature-Caps: *;+g.3gpp.atcf="tel:+1-237-888-9999"; +g.3gpp.atcf-mgmt= "sip:atcf.visited2.net";+g.3gpp.atcf-path="sip:termsdgfdfwe@atcf.visited2.net";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting Path:sip:termsdgfdfwe@atcf.visited2.net,sip:aga2gfgf@pcscf1.visited2.net:5070;ob Route: sip:icscf.home1.net;lr P-Visited-Network-ID: P-Charging-Vector: Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP ;comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee Max-Forwards: 68 P-Access-Network-Info: 二、用户呼叫流程：正常的IMS呼叫，但必须控制锚定媒体到ATGW 所有IMS呼叫都锚定到ATCF，ATCF需要知道用户是否支持SRVCC功能(这样才能控制SRVCC用户的呼叫媒体锚定到ATGW，并才能在呼叫、切换时进行特定处理)， ATCF在注册结束后，会从SCC-AS得到一个message消息：携带C-MSISDN、ATU-STI及用户是否支持SRVCC功能标记（即切换到CS域的功能）　SCC-AS如何知道用户是否支持SRVCC:UE在LTE中附着时，会指示自己是否支持SRVCC，MME将这种标记存入HSS。SCC-AS在用户注册时会从HSS下载用户数据，其中含SRVCC能力。所有IMS用户的IMS注册都被SBC发给Visited域的ATCF，ATCF把自己加到Path上，发给S-CSCF。后来这些用户（含SRVCC用户与非SRVCC，或分为：固定用户、Volte用户）的呼叫都经过了ATCF。ATCF根据在注册后得到的用户SRVCC能力来控制SRVCC用户的呼叫媒体锚定到ATGW（这是呼叫流程中最重要的工作），而非SRVCC用户则不需要锚定媒体。三、eSRVCC切换流程:STN-SR，ATU-STI， C-MSISDN 对于接受注册和VoLTE呼叫的ATCF来说，需要让MSC把切换请求发给自己。这样才是完全的“锚定”功能。 MME控制切换到CS域、PS域的方法与SRVCC一样。 eMSC在切换时，发invite给ATCF（其中带STN-SR，C-MSISDN)给ATCF。由于STN-SR是ATCF自己分配的，它会知道这是一个切换请求，并根据C-MSISDN关联到IMS用户和现有呼叫。对eMSC来说，这个操作与SRVCC方案中一样。区别只是：SRVCC中，呼叫是完全锚定到SCC-AS，由eMSC直接把切换invite发给SCC-AS。而eSRVCC中锚定由ATCF与SCC-AS共同完成，eMSC必须把切换invite发给ATCF。 STN-SR是给MSC在切换请求时使用的，由ATCF在注册时产生。一般是标识ATCF的全局PUI，或称为PSI，因为是给MSC用的，一般是Tel URI格式。当原IMS呼叫有几路时，ATCF收到MSC发来的呼叫中，必须选择关联其中一路：先选择Active的呼叫，再选择。。。这之中有个逻辑判断（由ATCF自己做）而ATCF发invite(被叫是ATU-STI，主叫是用户PUI)给SCC-AS。 SCC-AS返回SSI给ATCF和MSC。（SSI用于 mid-call 切换中关联呼叫所用） ATU-STI是给ATCF在切换请求时使用的，由SCC AS在注册时产生。 SCC AS在注册时产生ATU-STI。它用Message通知ATCF:UE的C-MSISDN，以及分配的ATU-STI，还有UE的SRVCC 能力 ATCF使用C-MSISDN来关联会话(MSC发来切换请求时)，使用ATU-STI替换与SCC AS之间的信令路径(在发起切换呼叫到SCC-AS时）。原信令leg会被ATCF或SCC-AS释放。 C-MSISDN是很重要的，因为IMS用户PUI与CS域号码可能是不一样的。ATCF收到MSC发来切换请求（带C-MSISDN，它表示了主叫的身份）时，再关联到现存的几个IMS呼叫中的一个。 ATU-STI 是全局PSI。像STN-SR一样，都是一个全局PSI，所以要关联到某个用户的某一路旧呼叫的话，要根据新呼叫中带的PAI(用于关联到用户）、Target-Dialog（像replace一样，含有旧呼叫的dialog ID) 用户原来有多路呼叫时，决定替换哪一路由ATCF决定，其原呼叫的dialog id 置入Target-Dialog参数中。当切换请求invite被eMSC发给ATCF，ATCF置被叫号码为ATU-STI（主叫号码为用户PUI），且携带Target-Dialog参数(其中含原LTE呼叫的SIP 会话ID），这个invite发给SCC AS。 SCC AS会执行替换呼叫的操作(不切换远端媒体)与释放原呼叫的local leg：SCC AS使用Target-Dialog参数来寻找到原呼叫的数据区。在invite的200 响应中，SCC AS携带Feature-Caps：*；+g.3gpp.srvcc 如切换请求(根据被叫是否是ATU-STI决定）的invite中没有携带Target-Dialog参数时（而不完全靠被叫是ATI或STN-SR来判断是否执行SRVCC），SCC AS执行SRVCC方案，即从用户的多路选叫中选中一路来update remote end.（SRVCC方案中，决定替换哪一路的决策由SCC AS来做）。而对SCC-AS来说，在收到ATCF发来用于切换的invite时，根据Target-dialog中的dialog id来关联到用户现存的4路呼叫中的一路。在这个呼叫关联完成后（呼叫关联的工作包括：向主叫用户即ATCF发送200OK，即完成新呼叫的创建，另外还要释放掉旧呼叫的leg。因为是B2BUA网元，所以不用通知到远端IMS用户，除非需要更新远端媒体)。 SCC-AS还要从剩下3路呼叫中选择一路呼叫来发起refer给ATCF-MSC，命令UE发起另一路呼叫的创建。依次选择几路呼叫的顺序也有一个逻辑判断（由SCC-AS自己做） LTE侧的IMS呼叫的振铃态切换的判断：当用户invite的contact中含有g.3gpp.srvcc-alerting feature tag时，它表示终端与ATCF 是否支持振铃态eSRVCC。SCC-AS可以根据这来判断是否做振铃态切换。在振铃态或媒体为inactive状态（即多路呼叫）的会话切换中,给ATCF发info消息,其包含Info-Package:g.3gpp.state-and-event-info和Content-Type:application/vnd.3gpp.state-and-event-info+xmls,及相关的XML描述。在呼叫消息中支持对Contact:sip:msc1.visit1.net:1357;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel"、Target-Dialog、Recv-Info、P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mmtel信息的处理,用于切换与判断是否支持振铃态和mid-call的切换。在响应消息中携带feature-caps头部。这是为了作振铃态切换。所有的切换请求、响应（18x,200)中都会带feature-caps:srvcc。用于标识eSRVCC切换呼叫。eSRVCC流程中出现了各种feature-code，携带各种关键参数。 ATCF没有锚定媒体其它技术点 IMS-HSS新增数据项 HSS的Sh接口透明数据中（29.328-b50)，有 MSISDN ：可能包括几个号码，即C-MSISDN, Extended MSISDN Additional MSISDN (A-MSISDN) Private Identity T-ADS Information -IMS-VOICE-OVER-PS-NOT-SUPPORTED (0) -IMS-VOICE-OVER-PS-SUPPORTED (1) -IMS-VOICE-OVER-PS-SUPPORT-UNKNOWN (2) STN-SR UE SRVCC Capability -UE-SRVCC-CAPABILITY-NOT-SUPPORTED (0) -UE-SRVCC-CAPABILITY-SUPPORTED (1) CSRN 在向IMS-HSS请求"MSISDN"时，需要在"User Identity"中填写PUI，在"User-Name"中填写PVI(从SIP注册消息的Authorization中获取). 控制非SRVCC用户呼叫不需经过ATCF的方法所有VoLTE用户中并非所有用户都是eSRVCC用户。或者部分用户是SRVCC用户、另一部分用户是eSRVCC用户。因为eSRVCC用户的语音质量更好，可能视为高端用户。这里的想法是：如何区分SRVCC用户、eSRVCC用户或非SRVCC用户。 eSRVCC功能要求：eSRVCC用户的媒体通过ATGW锚定，那么这些用户的注册、呼叫、切换信令是必须经过ATCF的。但其它非eSRCC用户是不需要让呼叫经过ATCF，仍经过P-CSCF-I-CSCF-S-CSCF即可。所有用户注册时（CS域 ICS用户，可能通过eMSC注册），注册信息必须经过P-CSCF-ATCF-I-CSCF。因为注册时，这些网元并不知道用户是否是合格的eSRVCC用户，甚至不知道是否是IMS用户。P-CSCF，ATCF会在用户注册时，将自己加到path路径上。这一点是没有异议的。有一种控制呼叫是否锚定到ATCF的方法是由S-CSCF在注册时判断用户是否支持SRVCC功能（S-CSCF在用户注册时，可以从Cx接口的签约数据中得到用户是否有SRVCC能力（目前的Cx标准 29228-b50 中没有这个信息））如支持，S-CSCF修改path头(使其中不含ATCF，用于被叫侧S-CSCF找下一跳）与产生service-route头(其中不需要含ATCF地址）（这里也要求S-CSCF能知道 path头中哪个URI是表示ATCF的，ATCF在注册消息的Feature-Caps中会带上自己的atc-path，另一种办法是让S-CSCF上配置ATCF域名），Service-route头在注册响应里原路返回发给P-CSCF,ATCF 等，UE把这个头反向复制到到新产生呼叫的route头中。 P-CSCF在收到呼叫消息时，删除信令中的service-route头（终端发来的，不可靠），按本身存储的service-route头再复制一份route头（当然会从中删除自己），这个呼叫消息会发给S-CSCF（不可能发给ATCF）如用户没有SRVCC能力，通过这种方法就可以控制呼叫消息不经过ATCF。这样：只有SRVCC的呼叫会经过ATCF。而普通IMS用户呼叫不会经过ATCF。缓存8秒的过程虽然锚定到ATGW的媒体端口、IP、编解码在切换前后没有变化，但信令路径发生了改变。所以ATCF需要发切换请求给SCC AS(因为原呼叫路径会自动释放)。原IMS呼叫路径包括了UE的IMS应用、SBC、P-CSCF、SCC-AS 都会因为session timer功能或刷新注册时间到却没收到刷新注册消息，而释放呼叫。（SCC-AS在释放呼叫或收到 ATCF侧发来的bye消息时，只释放这一边的leg ，远端leg 要保留）原IMS路径上的leg 释放，与 MSC发呼叫给ATCF ：这两个操作的时间顺序不确定。为了防止用户在session timer即将到期时发起切换，标准要求SCC-AS在收到释放近端leg的请求时，保留leg 8秒钟。 SCC-AS收到ATCF发来的新invite时，如原leg还在，SCC-AS会释放它。在手机信号变弱时，或原呼叫的session timer到期时，UE或CSCF会发bye，但此时对于SRVCC用户会发起切换。所以：要求ATCF、CSCF、SCC-AS 对于SRVCC用户的呼叫，在释放消息到时会缓存8秒。或只由SCC-AS来做，因为CSCF上没有用户信息，当CSCF主动发bye给SCC AS时，SCC AS缓存8秒即可。　CSCF的sesison time到期时，向上，向下都发bye。向下发给ATCF，ATCF也要缓存8秒，以防止这段时间内切换消息从MSC发来。如果CSCF不做这种缓存的话，就要求 SCC AS与ATCF 均要缓存8秒（如SCC有缓存，而ATCF不缓存的话，ATCF会在收到CSCF的bye时释放呼叫，后续当MSC发来切换请求时，就无法完成eSRVCC切换流程）。 eSRVCC是否兼容SRVCC eSRVCC的流程变化关键点体现在ATCF、SCC AS。如果要求网络中同时存在eSRVCC、SRVCC两种用户，比如对于高端用户提供eSRVCC流程，而eSRVCC流程要求ATCF的信令与媒体锚定，eSRVCC用户容量受ATCF与ATGW配置所限。　　ATCF、SCC AS通过注册成功可以鉴定用户是否是IMS用户，那么如何识别三种用户（普通IMS用户、SRVCC用户、eSRVCC用户)呢？ ATCF在注册时不区分是否SRVCC或IMS用户，由SCC AS从HSS得到用户支持C-MSISDN与SRVCC能力的参数，则证明用户支持SRVCC能力并经过SRVCC业务签约，SRVCC能力会在Message里下发给ATCF。这种方案支持eSRVCC用户漫游到外地:1,visited网有ATCF，则走eSRVCC流程。2，visited网没有ATCF，由P-CSCF接入home域IMS，SCC AS走SRVCC流程（SCC AS通过注册、呼叫消息中是否带feature-code来判断是否有ATCF接入）上述方案可以鉴别IMS用户与SRVCC用户(也含eSRVCC用户）。如何鉴别SRVCC用户与eSRVCC用户呢? 两种看法： 1，ATCF部署后，网络中只有eSRVCC用户，没有SRVCC用户（因为eSRVCC与SRVCC对终端的要求是一样的，只是网络侧能力不同）。则SCC AS只要发现用户注册、呼叫带了feature-code，则走eSRVCC流程。 2，ATCF部署后，网络中eSRVCC用户与SRVCC用户并存。SCC AS在HSS的用户透明数据中用特定业务属性表示用户是否是eSRVCC用户。 eSRVCC的缺点 eSRVCC也有人分析出不足之处： 1，不能适应高速移动场景：当在高速列车上进行切换时，时延还是太长。 2，复杂性：SCC-AS新增功能，引入新的 ATCF/ATGW网元。尤其是mid-call feature业务的复杂性。; 0 个评论

分享增强的过滤分析功能: kinghighland 2014-2-28 15:55; 支持对指定用户进行原始流的过滤分析; 694 次阅读|0 个评论

分享调查称iPhone用户忠诚度远高于三星: 热度 1 zzz 2013-8-20 08:39; 美国市场研究机构CIRP(Consumer Intelligence Research Partners)发布最新研究报告显示，iPhone手机用户度忠诚度远高于三星用户，过去一年中，42%的iPhone用户此前同样也使用iPhone手机。根据报告显示，在2012年7月至2013年6月期间，苹果新增的iPhone用户中，20%此前为Android手机用户；而三星新增的智能手机用户中，只有7%是iPhone用户，另外有43%此前使用Android手机，不过这些用户并不一定使用三星Android手机。; 766 次阅读|2 个评论

分享用户状告中移动“偷流量” 专家称可“自动续杯”: zzz 2013-8-12 11:03; 流量包缝隙“偷”走流量刚刚过去的7月，耿女士的手机话费比往常多了好几十元。查询详单后发现，自己竟然有56元的“套餐外上网费”。耿女士顿时纳了闷，“7月份，我除了当月话费套餐里包含的流量包以外，还单独又追加订了2个流量套餐包。” 喜欢用手机上网的消费者通常都会按照自己的上网流量需求定制一个流量包，而中移动(53.42,-0.40,-0.74%)会在流量用到90%时向用户发送一条提醒短信，提示流量即将用尽。这时，用户可以以几元钱的价格，继续加订2至16M的流量包，价格比零散地分段计费要优惠不少。耿女士证实，她正是在收到“流量仅剩10%”的提醒后，就迅速加订了流量包。“7月28号最后新加的流量包到了月底都没用完，怎么可能流量却用超了呢？” “您前一个流量包的流量用尽和下一个流量包生效之间产生了流量，这部分流量不计入流量包，须单独收费。”移动客服人员给出了这样的解释。耿女士这才明白，原来在她前一个流量包用尽、下一个流量包生效之前，有一个“缝隙”产生，在这个“缝隙”里发生的流量，任何一个流量包都不为其“买单”。“流量包本来就是给用户当月上网提供方便，凭啥独独不包括‘缝隙’？” 不仅流量包不为“缝隙”买单让她不满，连“缝隙”的产生过程也让她心生疑虑。耿女士翻出手机短信后证实，自己每次都是前脚刚收到10086“流量即将用尽”的提醒短信，后脚就立刻发送了订制新流量包的短信，按照10086官方“即时办理即时生效”的说法，她本不应有什么套餐“缝隙”产生。“这不是说不清道不明吗？套餐里的明明没用完，却还被单收了钱。” 套餐月底“清零”合理吗？ “为什么超出的流量要收费，剩余的流量却不能累计？难道没用完的流量我没交钱吗？”凭借这样一个反问，上周末，状告运营商的湖南律师刘明在网络上引起了一场关于运营商手机流量套餐如何设置才合理的热议。 “消费者用钱买的流量，凭啥没用完就清零。”网友“mangguowsp”十分赞同刘明。与她和刘明一样，对国内运营商套餐流量不能累积到下月使用的做法不满的消费者不在少数。不过，也有不少用户认为，已经享受优惠价格的套餐，其套餐内容本来就是有时效性的，非要坚持下月继续使用未免太过“矫情”。“如果刘明胜诉，那用户如果购买了无限流量包月套餐，岂不是买一个月就能用一辈子？”一位网友打趣说道。套餐月底清零究竟是否合理，国际运营商又是如何做的呢？多位通信界专家认为，流量本身所具有的时间属性决定了它“不可保留”。 “流量其实只是便于运营商和用户结算收费的计量单位，从本质上讲，它是运营商在特定时间向特定用户提供相关网络设备的使用权。流量的消费和生产是同时进行的，既不能提前生产，也不能像食物等生活消费品一样储存，留待消费者以后使用。”埃森哲广州分公司电信媒体和高科技部总监在其微博认证账户“我是二姐夫”中说。据了解，大多数国外运营商，如美国的Verizon，英国的Vodafone，其月流量套餐也都采用当月用不完剩余流量自动作废的计费方法。不过，业界人士也提出，从技术上来讲，将用户套餐中剩余的上网流量、通话分钟数、短信额度转移到其他月份使用，对运营商来说并非难事。只是理论上来讲，消费者已经通过“套餐”中拿到了固定时间段内的优惠价格，再要求将优惠部分转移到其他时间使用，难免有些苛刻。他山之石运营商可“自动续杯” 通信专家、独立电信分析师付亮认为，围绕上网流量的纠纷和用户意见层出不穷，流量套餐用户用超了也不满意、用不完也不满意，套餐内外差异太大，是上网流量纠纷频出的主要原因。 “运营商2G资费中标准流量资费、套餐外流量资费都明显高于套餐内，有些运营商的标准流量资费甚至达到10元每M以上，套餐内外资费相差几十倍，这才导致用户流量用超了不满意，用不完也不满意。”付亮说，简化套餐、将流量标准资费降到1元每M以下，可能是运营商唯一的解套办法。记者在ATT、Verizon等国际运营商官方网站查询其业务订制规则，并采访几位在美国、英国生活的手机用户后发现，状告长沙移动的律师刘明、抱怨流量包不该有“缝隙”的耿女士遇到的问题，如果能借鉴国际运营商的经验，其实都能寻得解决之道。以ATT为例，用户订制了20美元300M的流量套餐后，一旦流量超过套餐用量，系统会为用户“自动续杯”，自动追加一档流量套餐，无须用户手动追加。如此一来，耿小姐不明不白遭遇流量包“缝隙”的问题便迎刃而解。; 416 次阅读|0 个评论

分享工信部：上半年用户月均使用122.8M移动流量: zzz 2013-8-7 15:23; 工信部昨天公布的数据显示，上半年，我国的信息消费规模达到2万亿元，其中移动互联网流量消费成为亮点，用户月均接入流量达到122.8M。上半年，全国信息消费规模达2.07万亿元，同比增长20.7%。其中，通信业务收入5642.6亿元，同比增长8.9%；软件技术服务消费8345.8亿元，同比增长24.5%。新闻配图(图片来自互联网) 在信息消费中，移动互联网流量消费依然是亮点，基于智能终端的网络信息服务普及加快，用户月均移动互联网接入流量达到122.8M，同比增长36.6%，移动互联网流量收入增长55.8%。; 441 次阅读|0 个评论

分享求邀请码: LTE目标 2012-10-15 10:43; 目前，论坛针对新注册用户采取了购买邀请码的方式注册。价格为2元/1个。在点击注册时说明了收费的一些背景和原因但为了表示对论坛老用户的大力支持，特举办发日志得邀请码活动。只要点击右上角“快捷导航”选择“任务”领取任务就可以通过发表日志的方式免费获取邀请码了。您可以将邀请码分发给您的同事、朋友，壮大家园的队伍。再次感谢大家这1年多时间的陪伴。谢谢！我先发一篇日志，得一个邀请码！！; 629 次阅读|0 个评论

GMT+8, 2024-4-24 10:45 , Processed in 0.035809 second(s), 15 queries .

回顶部

		自动登录	找回密码
密码			立即注册

标签: 用户

相关帖子

相关日志