url无效u校园,5G标准会议联想投票事件的真相是怎样的?

2023-12-03 23:00:09 29阅读

1、url无效u校园，5G标准会议联想投票事件的真相是怎样的？

真相只有一个，本来这件事我也是看的云里雾里的，后来实在忍不住自己当了一回侦探，给你们还原一下推理破案现场：

名词说明：

1、长码：information block size of eMBB data> X（X值待定，128 <= X <=1024 bits）。

2、短码：information block size of eMBB data <= X。

3、FFS：有待决定的意思。

4、WF：Way-forward ，是3GPP在技术讨论完之后的提案。

5、Turbo code (turbo码，以欧洲公司为主)

6、LDPC code（低密度奇偶校验码，以高通为主)

7、Polar code (极化码，以华为为主)

8、TBCC (咬尾卷集码，以欧洲公司为主)

9、Possible Agreements（会议打算通过的决议）

10、 Agreements（会议通过的决议，一般不会改）

11、NR（应该是“新表决”的意思）

第一节、技术说明

Polar code被采用为控制信道的编码，但这个既不是长码也不是短码，因为长短码只属于数据信道编码的讨论范畴，有的人说控制信道编码也分长码和短码，这是错误的说法。

数据和控制信道的区别和联系：

所谓数据信道（也就是有长短码区别的）：传输的是用户所要传递的数据，视频浏览，微信短信，电话服务等等。

所谓控制信道（这个没有长短码之分）：传输的是有关数据信道的信息，譬如，数据在哪里传，数据块的大小，等一些控制信息。

通常来说，数据信道编码所需要的码长范围远远大于控制信道，且数据信道编码需要支持高速率数据传输，相对控制信道而言有更高的硬件要求。下面表格1总结了数据信道和控制信道比较常见的码块信息比特长度。

表格1：数据信道和控制信道码块信息比特长度的通常范围

数据信道：Info Bit K From 40 to 6,000~8,000

控制信道：Info Bit K 20~100 (一般场景)

控制信道：Info Bit K Up to 300 bits (极端场景)

这个表格的例子列举了常见的数据信道和控制信道所要支持的信道编码码块长度。一个数据信道码块长度从40-bit到6,000～8,000-bit。一个数据信道的传输块可以包含几十甚至成百上千的码块，换而言之，数据信道的数据量可以比控制信道高几个数量级。而控制信道的码长一般在100以内便可以覆盖大部分应用场景（此处数据参照4G LTE，5G的控制信道设计尚未完成，具体范围是否变化还待定）。这并不意味着控制信道编码不如数据信道编码重要（而只是说明两种信道需要的码长范围不同），事实上恰恰相反，控制信道编码解码对5G整个的延时，功耗等都有着深远的影响。

控制信道的码长虽短，但却并不隶属于“长码”和“短码”中的任何一类。

其实3GPP标准中本无所谓长码短码的概念，报道中常见的长码短码来自于2016年10月里斯本（3GPP RAN1）会议关于“增强型移动宽带（eMBB）的数据码”的讨论。

2016年10月里斯本RAN1的决议[2]摘录见附录1。四点决定非常清楚：

a. 数据信道长码(informationblock size > X)用LDPC

b. 数据信道短码(informationblock size ≤ X)用Turbo, LDPC或者是Polar 有待3GPP 2016年11月份雷诺会议上再做决定

c. 长码短码载荷分界线 X 在128到1024 bit之间, X的具体值有待3GPP十一月雷诺会议决定。

d. 控制信道和URLLC（超可靠低时延通信）和mMTC（大规模物联网）的编码有待研究.

原文：

-------------------------------------------------------------

Agreement:

a、“The channel coding scheme for eMBB datais LDPC, at least for informationblock size > X

b、FFS until RAN1#87 one of Polar, LDPC, Turbo is supportedfor information block size ofeMBB data <= X

c、The value of X is FFS until RAN1#87, 128 <= X <=1024 bits, taking complexity into account

d、The channel coding scheme(s) for URLLC, mMTC and control channels are FFS”

-------------------------------------------------------------

由此可见，长码短码指的都是数据信道编码（a和b）。

控制编码的讨论是另外的研究课题（包含在d里面）。

也就是说Polar code最终被采用的是控制信道的编码，既不是数据码中的“长码”也不是“短码”。

而且控制信道编码，主要的争夺其实是在TBCC和Polar之间展开，具体的技术讨论也只是在2016年11月雷诺会议上才展开。控制信道编码本来不必在雷诺会议上决定，但作为数据控制信道编码一揽子妥协方案的一部分，最终决定以Polar code取代4G采用的TBCC。

第二节、Polar与LDPC之争

对于大多数公司来说，LDPC用于长码，几乎是无可争议，也是为了达到高吞吐率和硬件的高效率所必需的。绝大多数公司都认可即便短码有其他选择，长码都必须要用LDPC。

争议的地方在于短码，也就是最终的数据信道编码到底采用LDPC+LDPC、LDPC+Turbo还是LDPC+Polar？这也是这次联想投票的主要焦点！

一、长短码投票（2016年10月10日-14日里斯本会议）：

原文：

-------------------------------------------------------------

Question: How many channel coding schemes should be specified for the NR eMBB data channel:

1、（单一编码方案）:

① LDPC（长码和短码都用LDPC，LDPC+LDPC）: Ericsson, Sony, Sharp, Nokia, ASB, Samsung, Intel, QC, VzW, KT, IITH, IITM, Fujitsu, MotM（摩托罗拉移动部门）, Lenovo（联想）, KDDI

② Polar（长码和短码都用Polar，Polar+Polar）: HW（HUAWEI）

2、（组合编码方案）:

①T+L（长码用LDPC，短码用Turbo，LDPC+Turbo） Accelercomm, IMT, LG, NEC, Fujitsu, Orange

②L+P （长码用LDPC，短码用Polar，LDPC+Polar）ZTE, Etisalat, Mediatek, Nubia, Xiaomi, Coolpad, Neul, HW devices, OPPO, CATR, TDTech, Spreadtrum, Potevio, ITRI, IDC, DT, NTU

Note that the above questions give an approximate picture, though not necessarily complete.

Possible Agreements（打算通过，也就是初步的决定，这里Polar+Polar就出局了）:

Alt 1（LDPC+LDPC）:

- The channel coding scheme for eMBB data is LDPC（长短编码都为LDPC）

No（反对票24票）: HW, IDC, HiSi, DT, NEC, CMCC, LG, Spreadtrum, Neul, CATR, Xinwei, TDTech, OPPO, Coolpad, Xiaomi, HW Devices, ITRI, Mediatek, Accelercom, Nubia, IMT, Orange, ZTE, ZTE Microelectronics

Alt 2（LDPC+Polar）:

- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（长码方案为LDPC）

- Polar coding is supported for eMBB data for blocks smaller than X （短码编码为Polar）

No（反对票27票）: Sams, NEC, Intel, QC, LG, Nokia, ASB, MotM（摩托罗拉移动部门）, Lenovo（联想）, KT, Ericsson, CableLabs, ITL, Sequans, Acorn, Asustek, Mitsubishi, KDDI, Wilus, Accelercom, IMT, Orange, Sony, Sharp, Fujitsu, VzW, Docomo

Alt 3（LDPC+Turbo）:

- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（长码编码为LDPC）

- Turbo coding is supported for eMBB data for blocks smaller than X（短码编码为Tubor）

No（反对票33票）: HW, IDC, HiSi, Sams, Nok, ASB, KT, QC, Asustek, Spreadtrum, Mitusbishi, CATR, Xinwei, TDTech, OPPO, Intel, Coolpad, Neul, Wilus, Xiaomi, ITRI, Mediatek, Nubia, ZTE, ZTE Microelectronics, HW Devices, CableLabs, ITL, DT, VzW, KDDI, Acorn, Docomo

-----------------------------------------------------------

里斯本会议最终结果：

原文：

Agreement:（最终通过）

①、The channel coding scheme for eMBB data is LDPC, at least for information block size > X（长码编码最终选用LDPC，这个无异议）

·②、 FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X（短码编码待定，决定在2016年11月14日-18日的雷诺会议上再从Polar，LDPC和Turbo中挑一个作为最终的短码编码）

③、The selection will focus on all categories of observation, including overall implementation complexity, regardless of the number of coding schemes in the resulting solution (except if other factors are generally roughly equal)

·④、The value of X is FFS until RAN1#87, 128 <= X <= 1024 bits, taking complexity into account

⑤、The channel coding scheme(s) for URLLC, mMTC and control channels are FFS

-------------------------------------------------------------

这里可以看到，联想在选长短码的时候确实选了高通的方案，而且明确反对了华为的方案。

二、短码投票（2016年11月14日-18日雷诺会议）

很遗憾，翻遍里斯本和雷诺会议记录，我并没有找到相关投票记录，也就是说短码可能是直接讨论就通过了，反正我找不到短码的投票记录。

这也意味着联想关于短码投票这种说法，可能并不存在，他仅有的两次关于数据信道长短码的投票，一次将赞成票投给了高通的LDPC+LDPC，一次将反对票投给了华为LDPC+Polar。

（以上是2018年5月12日我的观点，之前是用关键词eMBB data channels（eMBB是5G的一个应用场景，这里可以简单看做是5G移动通讯信道编码）查找，并没有找到短码投票。2018年5月16日柳总发表声明后，我重新阅读了一下雷诺会议全文，发现确实有第二轮短码的投票，这是新的发现，补充一下）

1、第二轮短码投票，Turbo争取短码编码的投票：

原文：

---------------------------------------------------------------

R1-1613347 （这是第二轮Turbo争取短码编码的投票的提案）WF on channel codes for NR short block length eMBB data AccelerComm, Ericsson, Orange, IMT, LG Electronics, NEC

Proposal（建议）:

- Turbo code is adopted for information block size of eMBB data <= 1024（提议Turbo作为短码编码方案。奇怪的一点是，这里关于长短码设定的X值是1024bits，但后来X值好像变成了256bits，这些会议记录真是看的人头疼）

- Note: if some system design constraints are found during the work item, it may be desirable to revisit the value of 1024

---------------------------------------------------------------

2、第二轮短码投票，Polar争取短码编码的投票：

原文：

---------------------------------------------------------------

R1-1613307 （这是第二轮Polar争取短码编码的投票，我之前看错了，把它当做控制信道的编码投票了。这里联想确实投了Polar作为短码编码的赞成票，我之前说没有第二轮短码投票的说法是错误的！）WF on channel coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（联想）, Marvell, MediaTek, Motorola Mobility（摩托罗拉移动部门）, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn. Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xilinx, Xinwei, ZTE, ZTE Microelectronics

Bureau Veritas withdrew their support.

Proposal（建议）:

• Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 1024 bits（提议Polar作为短码编码方案，这里界定长短码的X值还是1024bits）

Objections（反对票）: Ericsson, Qualcomm, Nokia, ASB, Samsung, LG, ETRI, KT, VzW, Intel, Docomo, IMT, KDDI, NEC

Proposal（建议）:

• Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 255 bits（提议Polar作为短码编码方案，这里界定长短码的X值应该变成256bits了，≥256bits应该为长码，≤255bits应该为短码。）

---------------------------------------------------------------

3、第二轮短码投票，LDPC争取短码编码的投票：

原文：

R1-1613342（这是第二轮LDPC争取长短码的投票，这一轮应该确定了信道编码长短码都采用LDPC了） WF on channel coding for eMBB data Samsung, Acorn Technologies, Alcatel-Lucent Shanghai Bell, Ceragon Networks, Cohere Technologies, Ericsson, ETRI, European Space Agency, HCL Technologies limited, IAESI, Intel Corporation, ITL, KDDI, KT Corporation, Mitsubishi Electric, Motorola Solutions, NextNav, NEC, Nokia, Nomor Research, NTT Docomo, Prisma telecom testing, Qualcomm Incorporated, Reliance Jio, Sharp, SK Telecom, Sony, Straight Path Communications, T-Mobile USA, Verizon Wireless, WILUS Inc

Proposal（建议）:

• Adopt LDPC code as the single code for eMBB data channels

Proposal（建议）:

• Adopt LDPC code as the single code for eMBB data channels at least for blocks >=256 bits

Proposal（建议）:

• Adopt LDPC code as the single code for eMBB data channels

• It is not precluded to adopt Polar code as an additional code for small eMBB data blocks if the concerns on IR HARQ are resolved（不排除接受Polar作为替补短码编码，前提是IR HARQ的问题得到解决。）

Proposal（建议）:

• Adopt LDPC code as the single code for eMBB data channels（接受LDPC作为唯一的信道编码，包括长码和短码）

• Adopt Polar code for a physical layer control channels（接受Polar编码作为物理层的控制信道编码）

-------------------------------------------------------------

这里可以看到华为的Polar编码可能还是存在一定缺陷的。

三、控制信道编码提案（主要是Polar和TBCC竞争，并没有看到LDPC）：

1、Polar作为控制信道编码的提案：

原文：

-------------------------------------------------------------

R1-1613211（这应该是Polar的主要提案，我之前以为是推动Polar的提案，现在看来应该是主要提案，再吐槽一下3GPP的会议记录真难看懂。） WF on Channel Coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（联想）, Marvell, MediaTek, Motorola Mobility（摩托罗拉移动部门）, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xinwei, ZTE, ZTE Microelectronics

Bureau Veritas and CGC withdrew their support（Bureau Veritas和CGC撤回赞成票）.

Proposal（建议）:

• Polar is supported as the channel coding scheme for DL and UL control channels for eMBB (except FFS for very small payloads)（提议Polar作为信道控制编码）

------------------------------------------------------------

2、TBCC作为控制信道编码的提案：

原文：

R1-1613577（TBCC的提案） WF on coding technique for control channel for eMBB LGE, AT&T, Ericsson, NEC, Qualcomm

Proposal:

• For DCI, tail-biting convolutional code (TBCC) is adopted as a channel coding technique for NR

• For UCI with encoder input size [16]<=K<=100 bits, TBCC is adopted as a channel coding technique for NR

• FFS: enhancements to LTE TBCC including generator polynomials with larger constraint length, lower native code rate

--------------------------------------------------------------

3、一个建议上行控制信道编码采用Polar，下行控制信道编码采用TBCC的提案，就是和稀泥的：

原文：

R1-1613248 （这个感觉像和稀泥的提案） WF on NR channel coding Verizon Wireless, AT&T, CGC, ETRI, Fujitsu, HTC, KDDI, KT, Mitsubishi Electric, NextNav, Nokia, Alcatel-Lucent Shanghai Bell, NTT, NTT DOCOMO, Samsung, Sierra Wireless, T-Mobile USA

Proposal（建议）:

• Adopt LDPC as the single channel code for uplink and downlink eMBB data channels for all relevant info block sizes（接受LDPC成为唯一的数据信道编码，包括长码和短码）

• Adopt Polar as the channel code for the uplink control information（接受Polar作为上行信道控制编码）

– FFS for very small block lengths where repetition/block coding may be preferred

Adopt TBCC as the channel code for the downlink control information（接受TBCC作为下行信道控制编码）

--------------------------------------------------------------

4、雷诺会议最终结果：

原文：

--------------------------------------------------------------

Agreement:

①UL eMBB data channels（上行数据信道编码最终采用LDPC，包括长码和短码）:

a、 Working Assumption to adopt flexible LDPC as the single channel coding scheme for small block sizes (to be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, implementation complexity and flexibility)

b、 (Note that it is already agreed to adopt LDPC for large block sizes)

②、DL eMBB data channels（下行数据信道编码最终采用LDPC，包括长码和短码）:

a、 Adopt flexible LDPC as the single channel coding scheme for all block sizes

③、UL control information for eMBB（上行信道控制编码采用Polar）

a、 Adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)

④、DL control information for eMBB（下行信道控制编码采用Polar）

a、 Working Assumption to adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)

§ To be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, latency, power consumption and implementation complexity

第三节、总结

综上，里斯本会议记录和雷诺会议记录里都没有出现短码的投票结果，也就是所谓的联想在短码上弃权导致华为输掉编码之争的说法，很可能是以讹传讹（2018年5月16日，特来说明一下，这里有误，确实有第二轮投票，联想也确实投了Polar）。

联想在第一次长短码编码上有过两次投票，一次是长短码编码方案的选择上投了高通LDPC+LDPC的赞成票；另外一次是在华为的LDPC+Polar上投了反对票，两次投票对华为都不利。

不过华为这边，也存在着Polar编码本质上的一些问题，说是IR HARQ的问题没有得到解决，这也是3GPP没有选用Polar作为短码编码方案的原因之一。

联想在信道控制编码上倒是投了华为的Polar，但这个确实对Polar最终赢得信道控制编码的结果影响不大。

下面贴出两次会议记录文件下载地址（主要看Report）：

1、里斯本会议（2016年10月）：http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_86b/

2、雷诺会议（2016年11月）：http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/

2、我的InternetExploret打开说域名不存在怎么办？

首先要检查你的上网线路或ADSL适配器，以保证你的网络连接状态正常。如果仍然出现InternetExplorer浏览器无法打开网页或者其他某些错误导致无法浏览网站的情况，可按照以下步骤检查浏览器设置。

1.尝试按键盘上的“F5”刷新网页，如果仍然无法浏览网页，则依次选择IE菜单中的“工具”->“Internet选项”->“连接”，在“拨号设置”中确认选中的是“从不进行拨号连接”，然后点击“局域网设置”，确保其中的三个选项前面的方格为未选中状态，即空白，最后点击“确定”。如果设置完后浏览网页时出现“脱机状态下Web页不可用”，则需要点击“连接”按钮重新连接。

2.在桌面“网上邻居”上点击鼠标右键，选择“属性”（如果是Win2000/Xp还要选择“本地连接”属性），查看TCP/IP协议中的IP地址、网关、DNS服务器的设置是否与你的上网服务商提供的设置是否一致，大多数情况下都为“自动获取”模式。一、感染了病毒所致

这种情况往往表现在打开IE时，在IE界面的左下框里提示：正在打开网页，但老半天没响应。在任务管理器里查看进程，（进入方法，把鼠标放在任务栏上，按右键—任务管理器—进程）看看CPU的占用率如何，如果是100%，可以肯定，是感染了病毒，这时你想运行其他程序简直就是受罪。这就要查查是哪个进程贪婪地占用了CPU资源。

找到后，最好把名称记录下来，然后点击结束，如果不能结束，则要启动到安全模式下把该东东删除，还要进入注册表里，（方法：开始—运行，输入regedit）在注册表对话框里，点编辑—查找，输入那个程序名，找到后，点鼠标右键删除，然后再进行几次的搜索，往往能彻底删除干净。

有很多的病毒，杀毒软件无能为力时，唯一的方法就是手动删除。

二、与设置代理服务器有关

有些筒子，出于某些方面考虑，在浏览器里设置了代理服务器（控制面板--Internet选项—连接—局域网设置—为LAN使用代理服务器），设置代理服务器是不影响QQ联网的，因为QQ用的是4000端口，而访问互联网使用的是80或8080端口。这就是很多的筒子们不明白为什么QQ能上，而网页不能打开的原因。而代理服务器一般不是很稳定，有时侯能上，有时候不能上。如果有这样设置的，请把代理取消就可以了。

三、DNS服务器解释出错

所谓DNS，即域名服务器（DomainNameServer）,它把域名转换成计算机能够识别的IP地址，如深圳之窗（

如果是这种情况，有时候是网络服务接入商即ISP的问题，可打电话咨询ISP；有时候则是路由器或网卡的问题，无法与ISP的DNS服务连接。

这种情况的话，可把路由器关一会再开，或者重新设置路由器。或者是网卡无法自动搜寻到DNS的服务器地址，可以尝试用指定的DNS服务器地址。在网络的属性里进行，（控制面板—网络和拔号连接—本地连接—右键属性—TCP/IP协议—属性—使用下面的DNS服务器地址）。不同的ISP有不同的DNS地址，如电信常用的是202.96.134.133(主用)202.96.128.68（备用）。

更新网卡的驱动程序或更换网卡也不失为一个思路。

四、系统文件丢失导致IE不能正常启动

这种现象颇为常见，由于：

1、系统的不稳定表现为死机频繁、经常莫名重启、非法关机造成系统文件丢失；

2、软硬件的冲突常表现为安装了某些程序引起网卡驱动的冲突或与IE的冲突。自从INTEL推出超线程CPU后，有一个突出的问题是XPSP1下的IE6与超线程产生冲突；

3、病毒的侵扰导致系统文件损坏或丢失。

如果是第一种情况，可尝试修复系统，2K或XP系统下，放入原安装光盘（注意：一定要原安装光盘），在开始—运行里输入sfc/scanow，按回车。98的系统也可以用sfc命令进行检查。

如果是第二种情况，可以把最近安装的硬件或程序卸载，2K或XP的系统可以在机器启动后，长按F8，进入启动菜单，选择“最后一次正确的配置”，若是XP系统，还可以利用系统的还原功能，一般能很快解决问题。

如果是XP的系统因超线程CPU的原因，可以在BIOS里禁用超线程，或升级到SP2。（当然，XP如何升级SP2涉及到很多知识及要注意的问题，在此限于篇幅不再详述）。这种情况下，QQ里自带的TT浏览器一般能正常浏览，可改用一试。

如果是第三种情况，则要对系统盘进行全面的查杀病毒。

还有一种现象也需特别留意：就是能打开网站的首页，但不能打开二级链接，如果是这样，处理的方法是重新注册如下的dll文件：

在开始—运行里输入：

regsvr32Shdocvw.dll

regsvr32Shell32.dll（注意这个命令，先不用输）

regsvr32Oleaut32.dll

regsvr32Actxprxy.dll

regsvr32Mshtml.dll

regsvr32Urlmon.dll

regsvr32Msjava.dll

regsvr32Browseui.dll

注意：每输入一条，按回车。第二个命令可以先不用输，输完这些命令后重新启动windows，如果发现无效，再重新输入一遍，这次输入第二个命令。还有，如果是98的系统，到微软的网站上下载这个文件也许更简单，这个文件的下载地址是：

五、IE损坏

以上方法若果都不奏效，有可能是IE的内核损坏，虽经系统修复，亦无法弥补，那么重装IE就是最好的方法了。

如果是98或2K系统，IE的版本若是5.0，建议升级到6.0。

98的系统如果已经升级安装了6.0，那么在控制面板里点击添加/删除程序，将会弹出一个修复对话框，选择默认的修复，重新启动即可。

如果是2K+IE6.0或XP（自带的IE就是6.0的）的系统，重新IE有点麻烦，有两种方法：

1、打开注册表，展开HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ActiveSetup\InstalledComponents\{89820200-ECBD-11cf-8B85-00AA005B4383}，将IsInstalled的DWORD的值改为0即可；

注：重装IE并不一定就能解决问题，仅是一个处理问题的思路而已

3、如何解决浏览器不支持cookies？

浏览器不支持cookies可能是由于浏览器设置或安装的插件导致的。解决这个问题的方法有以下几种：

1. 检查浏览器设置：确保浏览器的cookie设置被启用。在浏览器的设置菜单中，找到隐私或安全选项，确保允许使用cookies的选项被勾选。

2. 清除浏览器缓存：有时候浏览器缓存中的旧数据可能导致问题。清除浏览器缓存可以尝试解决此问题。在浏览器的设置菜单中找到清除缓存的选项，清除缓存后重新启动浏览器。

3. 禁用插件：一些插件可能会干扰浏览器对cookies的支持。禁用或卸载可能引起问题的插件，然后重新启动浏览器。

4. 更新浏览器：如果您使用的是旧版本的浏览器，可能会存在一些兼容性问题。尝试更新到最新版本的浏览器，以获得更好的支持。

5. 使用其他浏览器：如果以上方法都无效，可以尝试使用其他浏览器，可能其他浏览器能够更好地支持cookies。

总结起来，解决浏览器不支持cookies的问题可以通过检查浏览器设置、清除缓存、禁用插件、更新浏览器或者使用其他浏览器来解决。

4、502错误网关是什么原因？

服务器（不一定是Web服务器）是作为网关或代理，以满足客户的要求（如Web浏览器或我们的CheckUpDown机器人）来访问所请求的URL 。此服务器收到无效响应从上游服务器访问履行它的要求。含义这通常并不意味着上游服务器已关闭（无响应网关/代理），而是上游服务器和网关/代理不同意的协议交换数据。鉴于互联网协议是相当清楚的，它往往意味着一个或两个机器已不正确或不完全编程。 502错误的HTTP周期任何客户端（如Web浏览器或我们的CheckUpDown机器人）经过下列循环时，沟通与您的Web服务器：获取IP地址的IP名称您的网站（您的网站URL的领导’ http:// ‘ ）。这查找（转换的知识产权名称， IP地址）所提供的域名服务器（ DNSs ）。打开一个IP套接字连接到该IP地址。写一个HTTP数据流通过该插座。收到一个HTTP数据流从您的Web服务器的响应。此数据流包含状态码的值是由HTTP协议。解析此数据流的状态码和其他有用信息。这个错误发生在最后一步时，上面的客户端收到一个HTTP状态码，它承认为502 ‘ 。