转载链接：http://bbs.c114.net/thread-920549-6-1.html

【更新】
1. 到底是什么是5G                                      2016.8.18   10:23
2. 自包含帧结构         
2-1. 自包含（Self-contained）帧结构 - 1   2016.8.18   23:07
2-2. 自包含子帧 - 2                                    2016.8.19   23:10
2-3. 自包含子帧 - 3                                    2016.8.20   17:35
3.多址
3-1 多址 - 引子                                          2016.8.26   16:14
3-2 多址 - 2                                               2016.9.6     22:04
3-3 多址 - 3                                               2016.9.10   22:46 
3-4 多址 - 4                                               2016.9.11   9:58 
3-5 多址 - SCMA                                       2016.11.24   22:16  
4.毫米波
4-0 毫米波                                                 2016.9.17  20:20
4-1 毫米波关键技术                                   2016.9.25  19:37 
4-2 毫米波的其他应用                                2016.9.25  20:35        
4-3 毫米波信道测量与建模                         2016.9.28  9:33
5低时延高可靠技术
5-0 低时延高可靠技术                                2016.10.11 19:30
5-1 资源分配 - 预留还是共享                      2016.10.22 13:59

1. 到底啥是5G

5G是正经5G，可惜被玩儿坏了。现在到处都说是5G技术，例如全双工，已经明确的被排除出5G的备选技术。还有一些技术（重灾区是多址）注定会被大量淘汰，据说现在在提案中出现八种多址技术，楼主估计NR最终最多接受三种：eMBB两种（DL、UL），IoT接受一种（UL）。其他还有一些其他备选技术也有点悬，例如编码。

5G的正式定义来自于ITU。ITU的技术报告给出明确的三个场景、需求（KPI）、时间表（标准制定、提交、验证）。

任何的标准组织（包括3GPP、IEEE、甚至CCSA）都可以按照要求的时间（2020年Q3）提交完整的解决方案，通过ITU指定的第三方机构验证后，能够满足ITU需求的的方案就被认定为5G标准。

在3G阶段，通过验证，满足需求的标准有几个（CDMA 2000，WCDMA，TD-SCDMA，WiMAX），所以被称为IMT-2000 family。

到了4G（IMT-Advanced），虽然3GPP2和IEEE都有各自的计划，但是因为缺乏运营商支持，最终都没得到实行。实际的4G标准只有来自3GPP的LTE-Advanced （Release 10 and forward)。

5G的正式名字是IMT-2020，值得一提的是，这个名字最早是国内提出的。CAICT（信通院）领导的5G推进组英明的首创了IMT-2020这个名字（据说还注册了商标），最终被ITU采纳。

2015年6月，ITU定义了IMT-2020的需求，目前已经进入评估准备阶段。在ITU-R WP5D工作组下设立了评估工作组，正在制定评估方法和报告模板。再次值得一提的是，评估组的co-chair是中国代表彭莹。

ITU制定了计划、需求，5G还是需要具体的标准组织（SDO）落地的。目前，只有3GPP公布了完整的5G标准制定计划。计划在2019年完成全部标准，满足ITU的3个场景（eMBB、Massive IoT和URLLC）的全部KPI。其他标准组织里，IEEE近期也提出了5G计划（两种方案）：采用双连接（或多连接）的方式接入3GPP 5G NR空口和提供融合了IEEE802.1多种接入方式（11ax、11ay等）的独立接入网。

对应于LTE，3GPP的5G空口技术被称为New Radio（NR）。如果没有意外，未来的5G空口技术将被称为5G NR。

2 - 1. 自包含（Self-contained）帧结构 - 1


想来想去，还是先写帧结构吧，毕竟这个对中国标准界和我都有特殊的含义。

不得不从LTE TDD的帧结构说起。

LTE项目在3GPP启动之后，国内也开始了研究工作。主要思路之一就是延续TD-SCDMA的思路，设计LTE TDD方式的技术方案。由于LTE TDD比较拗口，同时也为了和TD-S统一，改称为TD-LTE。开始老外不太明白TD-LTE是啥，后来慢慢也就认可了，现在还有一个全球性的TD-LTE推进论坛，就叫Global TD-LTE Initiatives，简称GTI。

当时的设计思路是与TD-S共享频谱，需要考虑邻频共存。由于TDD最大的干扰是交叉干扰（干扰源BS发送干扰受害BS接收），所以邻频共存就得到了一个必然的结果：TD-L的帧结构必须与TD-S完全一致 - 即0.625ms的子帧。这个设计在3GPP研究报告存在了很长时间，直到欧洲公司为了保证LTE FDD和TD-LTE设计的最大一致性，强行revise结论。TD-L的子帧被设计为和LTE FDD一致的1ms，相应的符号长度和CP长度也用了完全一样的设计。期间还有个小插曲，国内的某些领导不太满意TD-L帧结构被称为Alternative Frame structure，认为Alternative显得TD-L和LTE FDD似乎不对等，要求3GPP改为type 2 Frame Structure.

2-2. 自包含子帧 - 2 

在3G、4G时代，TDD系统虽然是主流标准之一，但由于TDD频段偏高，网络覆盖较差、运营商投资高，除了中国的特殊国情以外，其他地区主流运营商采用TDD系统独立组网、运营的并不多。

话说到了5G时代，情况不太一样了。首先是新的FDD频率实在太难找了，唯一的可能就是二次数字红利（DD，Digital Dividend）广播业务退出的频段（600MHz），但这个频段涉及到广电清频这种多个行业协调问题，推动缓慢，目前只有美国进入了拍卖阶段。其次，1.8GHz – 2.6GHz之间这段频率基本都处于3G或4G的现网运营状态，何时重耕需要看政府的策略和运营商的商业计划。但是5G需要的频率量之大前所未遇，DD和重耕都不能解决实质问题，更多新频率只能在3.5GHz以上发挥了。从3.5GHz到70GHz，几乎所有的IMT备选频率都是TDD划分。

总结成一句话：5G时代真的要看TDD了。

吸取4G时代TD-LTE的设计经验，结合被广泛看好的Massive MIMO技术，5G时代TDD系统设计主要有两个目标：
1. 更快的系统反馈：为了提供更低的端到端传输时延，5G系统需要更低的RTT （消息往返时间，Round Trip Time）。在TD-LTE帧结构的七种配置中，最快的反馈大约是1ms；如果不幸的配置成了8:1的配置，最慢的系统反馈将是9ms。
2. 更快的信道测量：MIMO在TDD频段使用最大的优点是利用信道互易性，通过测量上行导频获得下行信道部分信息（波束方向）。考虑到毫米波频段的信道快速变化，5G的 TDD系统需要提供更多的上行导频发送时机。

从快速反馈的需求出发，最直接的设计就是同一个子帧里同时包含DL、UL和GP。下图是RAN1 #85会议提案中的示意图。

图（a）是自包含子帧，具备三个特点 ：
•        同一子帧内包含DL、UL和GP
•        同一子帧内包含对DL数据和相应的HARQ反馈
•        同一子帧内传输UL的调度信息和对应的数据信息

考虑到自包含子帧对硬件处理能力的要求很高，低端手机可能不具备相应的硬件能力，提案中也包含了图（b）中的较低要求方案。这种方案中HARQ反馈和调度都有更多的时间余量，对终端硬件的处理能力要求较低。而且，自包含子帧很容易通过信令指示终端支持这种配置。

在Verizon的V5G方案中关注到了MIMO信道测量这个问题。通过在同一个子帧内同时包含DL、UL和GP，利用UL发送RS进行信道测量。但是V5G对HARQ反馈时延要求不高，不必在同一子帧内反馈。

TD-LTE帧结构设计主要考虑了两个问题：当相邻小区UL/DL不能对齐时相邻小区的交叉干扰和GP对于小区覆盖的影响。相比于传统TDD帧结构设计，自包含子帧提供了更大的灵活性，但它是否会面临TD-LTE设计时同样的挑战呢？
•        首先是相邻小区的交叉干扰。如果相邻小区采用不能完全对齐的UL/DL配置，会有一个时间片段存在交叉部分。自包含子帧在设计时考虑了一些措施：首先将DL控制部分完全对齐，避免最重要的控制部分受到干扰；其次在数据部分通过纠错编码、HARQ等技术对抗干扰带来的影响。
•        其次是较小的GP限制了小区覆盖范围。小区的覆盖范围取决于GP的大小，即小区半径R=C（电磁波速度，即光速）* GP/2。但高频率无线电波在空气中传播损耗大，本身覆盖范围有限，相应的GP长度很小。也就是说，这个问题在载频变高后就不再是主要矛盾了。

在5月的南京RAN1会议，自包含子帧的基本设计在E、Q、Z、D几家公司共同的推动下获得了通过。可以预测，自包含子帧对5G物理层的设计会起到支柱性作用，3GPP将以此为基础，结合sub-carrier spacing等参数，尽快完成帧结构设计。

2-3. 自包含子帧 - 3

直面自包含子帧时延挑战 – Scaled Symbol Control Design

ITU的IMT-2020.VISION对5G（IMT-2020）空中信号传输时延提出了1ms要求：
“IMT-2020 would be able to provide 1 ms over-the-air latency, capable of supporting services with very low latency requirements.”

自包含子帧的设计目标之一就是在同一子帧内通过反馈UL ACK，保证低时延。可是，问题来了，手机是否真的能那么快的处理信号、并生成反馈呢？

自包含子帧示意图（DL Centric）

在示意图中，为了通过快速反馈降低时延，UE会在同一个子帧内的UL符号传输针对DL数据的ACK。假设DL数据占用T0 -> T1的全部符号（蓝色），一个能够充分利用流水处理接收信号的UE会在接收到每一个DL符号之后，马上开始开始解调，解码等处理（充分流水处理也即是自包含子帧的设计理念之一）。UE将在T1 + TLatency （BS到UE的空口传输时延）时刻接收全部DL数据，在这之后大致还需要一个符号的时间来处理最后一个DL符号的数据。

为了保证小区内各个UE信号同时到达BS，UE需要在T2 - TLatency时刻发送UL ACK。也就是说，留给UE处理数据的时间大约是T2 – T1 – 2×TLatency。为保证UE有足够的处理时间，似乎必须得在帧结构里预留一个额外的符号作为数据处理时间。

举个例子：假设UE处理DL数据的时间TD较大（即TD > T2 – T1 – 2× TLatency），在帧结构设计时需要预留灰色部分来保证UE有足够的时间处理DL数据，即T22 – T1 – TLatency ≥ TD。假设小区半径1公里，空口往返延时大约6us，数据处理时间大致为一个符号35us，数据处理时间远远大于空口往返延时。

很自然的想到，难道大部分灰色部分只能空着吗？能不能传点有用的数据呢？能想到这个，就必须给你点赞了。

仔细分析控制信道设计会发现，控制信道总可以归纳为两部分，一部分没有数据依赖性，另一部分则具有数据依赖性。UE可以在这个灰色时间区间发送与DL数据接收无关的信息，例如导频。把UL ACK分成两个较短的符号传输。第一个符号传输与DL数据接收无关的导频可以在数据处理的同时发送，第二个符号传输ACK在数据处理完成后再发送。这时，只要保证缩短符号（Scaled Symbol）的长度小于TD就可以了，既给UE留了足够的时间接收DL数据、生成ACK，又充分利用了时间资源。不仅如此，Ack到下一个子帧之间又留出了时间，这样不仅自包含同帧Ack实现了，子帧间无间断的HARQ处理也成为了可能！

再看复杂度，缩短符号相应的FFT  size 变小了，也更便于基站接收UL  ACK的流水作业（即在原本只收到半个符号的时间点就可以开始处理导频信号了），总的复杂度不增反降，真可谓两全其美。

那么，这样做有什么代价吗？会不会影响UL传输性能呢？

假设缩短符号是按比例缩短，即CP也缩短一半，这时对抗（多径造成的）时延扩展能力会相应下降。对于UL控制信道（导频和ACK），这个影响有多大呢？

30KHz符号和60KHz符号的设计参数

下图是信道时延扩展为300ns时的Geometry分布。可以看到：在Geometry较大的区域（大于22dB），Scaled CP性能开始下降。但是，采用UL缩短符号传输控制信道需要传输的仅仅是1个比特，码率非常低，Geometry工作点远远低于22dB。因此，缩短符号对控制信道的影响可以基本忽略。

3-1 多址 - 引子

5G多址有两个特点：

第一是从来没有这么公司观点如此统一：5G需要新的多址；

第二是从来没有一个技术有这么多竞争方案。

先卖个关子，说一下现有的多址技术。

教科书上写了不少，就不多说TDMA了。

到了3G时代，作为主要的技术创新点，多址技术被提到了前所未有重要程度，甚至系统都用多址技术来命名 - CDMA、TD-SCDMA、WCDMA。这三种技术本质都是使用不同的码字来区分用户地址，最初的来源都是一位美女发明家海蒂.拉玛（Hedy Lamarr）的一个想法。民用CDMA技术最大的贡献者是Qualcomm，主要解决了组网问题。关键的技术包括功率控制、软切换、Rake接收等等。在CDMA IS-95出现后，欧洲的ETSI也意识到了下一代技术的趋势会是CDMA。但是，作为后来者的ETSI面临着技术先行者Qualcomm设置的巨大专利池。为了尽量绕开专利，WCDMA采用了不同的码字设计，但是并不能避开基本的CDMA组网专利（功率控制、软切换、Rake接收等），这也是Qualcomm在3G时代声称具有核心专利的原因。

在2007年，WiMAX赶上了3G时代的尾巴，进入了IMT-2000 family。它最大的贡献就是将OFDMA技术引入了蜂窝通信系统。相比于CDMA这种窄带多址技术，OFDMA对于可扩展的宽带系统支持更好。同时，相比于传统的FDMA，OFDMA通过完全正交的相邻子载波1/2重叠，提供更高的频谱效率。OFDMA很快引起了业界的极大关注，俨然成为4G的重要备选方案。换句话说，OFDMA此时已经成为最大的移动通信技术“网红”。

IEEE力推WiMAX进入IMT-2000 family有两层含义：首先是为了使用ITU为3G划分的频率；更深一层的含义是在4G时代与3GPP正面竞争。IEEE推出的4G技术是WiMAX（802.16e）的演进版本 – 802.16m。出身较晚的WiMAX标准由于采用了OFDMA等技术，在物理层设计显示出了强大的竞争力。3GPP再次感受到了来自WiMAX的挑战和4G时代的危机。为了迎接来自16m的挑战，3GPP在LTE系统中引入OFDMA和MIMO技术，显著的提升了系统的频谱效率。同时，3GPP在自己擅长的电信网络架构方面提出了“扁平化”的低时延设计。故事的结果相信各位读者已经很熟悉了，16m由于缺少运营商的支持，最终被终止了。

虽然IEEE的802.16m失败了，但是WiMAX和16m带来的多址技术 – OFDMA取得了巨大的成功。这也是迄今为止，我们能找到的最好的移动宽带系统多址方式。

那么，为什么还会有那么多5G的备选多址技术出现呢？且听下回分解。

3-2 多址 - 2

真心后悔没有及时写完多址技术，最近三次RAN1的会议的多址技术居然呈现线性增长，搞得越写越多了。

到了八月下旬的RAN1#86，居然出现了十五种多址提案。上次会议（RAN1#85）还只有不到10种，再上次会议才几种...

这些多址技术有一个共同点，都是非正交多址，目前简称NOMA。

先分辨一个小概念 - NOMA。截止目前为止，出现过两次NOMA，分别是rel-13的LTE和rel-14的5G NR。

在Rel-13的时候，日本的NTT DoCoMo推动了一种功率域的非正交多址技术，叫NOMA。主要思路是把信道质量（SNR）相差很大的两个用户（UE1、UE2）配对，在同一个时频资源块上发送。假设UE1离基站很近，UE2离基站很远。UE2需要做串行干扰消除（SIC），把另一个UE的信号减去，得到本身的信号。好处很明显，资源利用率提高了，缺点就是UE需要引入SIC接收机，复杂度提高了。这种NOMA其实还有个学术的名字叫superposition coding，后来3GPP立项就用了这个名字叫MUST - Multi-User Superposition Transmission。根据理论分析，功率域的superposition可以把信道容量提升一些，画成图形就是直线被上拉成了抛物线。

另一个就是rel-14 5G的NOMA了。这次是一类技术的名称，就是指Non-Orthgnal MA。为什么要在5G提NOMA呢？主要是针对物联网（IoT/MTC）场景提出的。对于IoT来说，每次传输的数据量非常小，按照传统的UL资源请求、传输方式非常不划算。就是说建立连接需要的控制信令数据量已经超过payload本身了，划不来啊。而且时延也挺大，更关键的是IoT重要指标之一是省电，NB-IoT提出的指标是5W/H的电池用10年。传统的资源请求、传输的流程增加了耗电。很自然的提出一个问题：能不能减少两个步骤，变成直接竞争传输呢？这就是Grant Free或者叫Contention Based概念 - UE不请求资源，直接在UL发送。这样碰撞的概率就会增加，需要设计一种方法，在碰撞的情况下也能正确解出信号，这就需要NOMA技术了。因为NOMA可以提供非常大（比正交多址大很多）的地址空间，这样随机选择地址并碰撞的概率就大大降低了。

华为的SCMA、ZTE的MUSA、大唐的PDMA都是这类技术。其实本质都是构造一个非正交向量空间，供UE选择并传输。国内很看重多址的创新，也作为主要技术创新点大力推动。但是这种非正交多址技术其实并不是第一次提出，最早在移动通信系统中应用是CDMA2000时代，当时也是为了解决地址不够的问题，高通提出了非正交CDMA技术。这次，高通提出的RSMA技术就是非正交CDMA技术的升级技术。区别只是在于构造非正交向量的空间方法不同。

3-3 多址 - 3

如果问主席：问君能有几多愁。主席肯定说看看多址方案就知道了。

在今年四月的RAN1#84bis上，主席报告归纳了所有的NOMA方案，一共是八种。

• For UL, Multi-user shared access (MUSA) (e.g., R1-162226)
• Resource spread multiple access (RSMA) (e.g., R1-163510)
• Sparse code multiple access (SCMA) (e.g., R1-162153)
• Pattern defined multiple access (PDMA) (e.g., R1-163383)
• Non-orthogonal coded multiple access (NCMA) (e.g., R1-162517)
• Low code rate spreading (e.g., R1-162385)
• Frequency domain spreading (e.g., R1-162385)
• Non-orthogonal multiple access (NOMA) (e.g., R1-163111)
  

到了八月的RAN1#86会议上，主席报告再次归纳了所有的NOMA方案，就变成15种了。

• Sparsecode multiple access (SCMA) (e.g., R1-162153)
• Multi-usershared access (MUSA) (e.g., R1-162226)
• Lowcode rate spreading (e.g., R1-162385)
• Frequencydomain spreading (e.g., R1-162385)
• Non-orthogonalcoded multiple access (NCMA) (e.g., R1-162517)
• Non-orthogonalmultiple access (NOMA) (e.g., R1-163111)
• Patterndivision multiple access (PDMA) (e.g., R1-163383)
• Resourcespread multiple access (RSMA) (e.g., R1-163510)
• Interleave-GridMultiple Access (IGMA), (e.g., R1-163992)
• Lowdensity spreading with signature vector extension (LDS-SVE) (e.g., R1-164329)
• Lowcode rate and signature based shared access (LSSA), (e.g., R1-164869)
• Non-orthogonalcoded access (NOCA), (e.g., R1-165019)
• InterleaveDivision Multiple Access (IDMA), (e.g., R1-165021)
• Repetitiondivision multiple access (RDMA), (e.g., R1-167535)
• GroupOrthogonal Coded Access (GOCA), (e.g., R1-167535)
  

主席哭了，不带你们这样的。不但没有按说好的down selection，还增加了7种。于是，主席生气了，在会场说，下次会议（RAN1#86bis）是最后一次讨论多址了，必须得有结论。大家听到后也凌乱了。

这么多多址技术既然都是CDMA扩展技术，怎么分析、比较呢？

R1-166358给出了一些分析方法。按照扩频序列来区分：伪随机长扩频码和固定码本短扩频码。

伪随机长扩频码的代表是RSMA；
固定码本短扩频码的代表是：

• 
  
  
  • Sparse code multiple access (SCMA) (e.g., R1-162153)
  • Pattern defined multiple access (PDMA) (e.g., R1-163383)
  • Non-orthogonal coded multiple access (NCMA) (e.g., R1-162517)
  • Low code rate spreading (e.g., R1-162385)
    

对于NOMA技术来说，长码空间更大，碰撞概率更低，同时伪随机特性也更好，但短码可以简化多用户检测，简化接收端接收机设计。从缺点角度看，短码首先需要预先设计和优化，在传输中可能需要进行额外的功率回退避免码字不够随机而造成的PAPR，影响链路预算。

很多文献都进行了仿真比较，篇幅所限，这里就不放了。

但通过分析后结论是类似的：

1. 伪随机扩频性能更好一些，这个在CDMA时代就证明了；
2. 固定码本的扩频方法由于码字短，需要预先搜索定义优化码本。

3-4 多址 - 4

说了这么久，都是NOMA技术，难道OFDMA和SC-FDMA就不用了吗？

恰恰相反，NR正是要在eMBB场景继续用OFDMA和SC-FDMA。

下行OFDMA没什么悬念，唯一的悬念在于上行是用SC-FDMA还是OFDMA。

用OFDMA的好处在做LTE D2D的时候就讨论过，如果上行也用OFDMA，那么手机在发送D2D信号时就比较简单，可以和宏蜂窝的上行信号完全正交，并同时FTT发送。

但是缺点也比较明显，就是为了避免PAPR带来的功率回退（Power Backoff）会导致上行的覆盖（链路预算）减小。据当前分析，大概会有1-2dB的链路预算损失。

因此，预计上行采用SC-FDMA的可能性较大，毕竟已经被LTE验证过了。

前言

虽然在前后端分离的大潮流中，jsp技术已经是很少被使用了，其中一个重要的原因是jsp展示页面的时候过慢。但是，作为sun官方推出的技术，其中的思想和今天的前端技术十分的相似，很多前端框架都是基于这些思想的。所以，学习一下jsp还是十分有必要的。

Jsp的原理

简单来讲，使用jsp技术，可以将java的代码使用<%%>标签嵌入到html页面当中。
但是，为什么可以这样用呢？
比如说，现在有个页面叫做a.jsp。当你访问它的时候，服务器就会作出相应的响应，将jsp页面编译成Servlet实例，你不知道Servlet也没有什么关系，这玩意其实就是一个服务器的逻辑处理部分，能够把前端传过来的值进行处理并作出相应的响应。早期的web开发都是用的这个，但是这东西开发起来有些麻烦，已经渐渐使用的少了，但是作为基本内容，同样是十分的重要。
注意：只有当客户端第一次访问服务器的时候才会进行编译，第二次再访问的时候，客户端就可以直接获取到生成后的页面了。

Jsp的基本内容

• Jsp注释
  注释语法：

<%--这里写注释内容--%>

• Jsp声明
  语法：

<%!声明的内容%>

请注意，声明中的内容最终会被转换成Servlet的成员变量和成员方法，所以在声明变量的时候就可以使用public、private等修饰符号，但是绝对不能使用abstract进行修饰，因为这样会导致Servlet也变成抽象类，就会造成无法实例化的情况。这样是绝对需要避免的。

• Jsp输出
  输出语法：

<%=输出的内容%>

其实这条语句同样可以用out.println方法进行作为替换，但还是这样简单的一条语法较为简单。但是还有一点，使用输出语法的时候，java代码的末尾不需要加分号，其他的就需要加分号了。

• Jsp脚本
  所谓的jsp脚本，其实就是将java语言写在<%%>这条语法中，来操作数据而已。

<%
        //注册数据库
        Class.forName("com.mysql.jdbc.Driver");
        //获取连接
        Connection connection = DriverManager.getConnection(
                "jdbc:mysql://localhost:3306/keyan","root","root");
        //创建一个语句
        Statement statement = connection.createStatement();
        //创建一个查询语句
        String sql = "SELECT * FROM e_person";
        //使用查询
        ResultSet rs = statement.executeQuery(sql);
        while(rs.next()){

%>
    <table border="1" bgcolor="#ffd700" width="250px">
        <tr>
           <td>工号：<%rs.getString(1);%></td>
            <td>姓名：<%rs.getString(2);%></td>
        </tr>
    </table>

    <%}%>

上面这段jsp脚本，其实就是常规的用java链接数据库的操作。
注意：jsp脚本中的内容都是使用servlet中的方法进行输出的，所以，很显然在jsp脚本中是不能定义方法的。

Jsp编译命令

所谓的jsp编译命令，就是在通知服务器的jsp引擎，我需要什么东西、我有什么东西、、我是什么格式等等内容。
比如说导入一个java包，设置一些属性等等操作。

• page指令

<%@ page 属性=""%>

page指令又如下的属性，使用page指令就是操作这些属性而已。
具体的属性以及操作，可以参考这篇博客：jsp中page的各个属性介绍
还有一点，Jsp内建了异常处理机制，所以在脚本中就不需要对异常进行处理了。
- include指令

<%@ include file=""%>

这个指令可以将另外一个文件加载到当前的页面之中。

• taglib指令
  这条指令暂时不做介绍。

Jsp的动作指令

• forward指令：将页面转发到另外一个页面

<jsp:forward page="roobtyan.jsp">
    <jsp:param name="roobtyan" value="go"/>
</jsp:forward>

访问当前网址的时候，会转发到roobtyan.jsp这个页面。并将参数name和他的值传到这个页面。

• param指令 ：用于传递参数，需要和支持参数的标签一起使用
  使用的方法如上面的例子所示。
• include指令 ：动态引入一个jsp页面

<jsp:include page="roobtyan.jsp">
    <jsp:param />
</jsp:include>

请注意这里的include不同于编译指令中的include。这里的include是动态的导入，而之前的是静态导入。动态导入后，被导入的jsp页面的编译指令失去作用;而静态导入则不会出现这种情况。
还有一点，使用这个引入的时候，也是可以加入参数的。

• plugin指令 ：下载javaBean到页面执行
  基本上已经不再使用了，这里就不介绍了。

• useBean指令：实例化javaBean
  语法格式：

<jsp:useBean id="name" class="className" scope="page"/>

id是实例化的名称，class是javaBean（类）的名称，scope是可用范围，这个后面会介绍。

• setProperty指令：设置javaBean实例属性值
  实例化的方式：

<jsp:setProperty name="name" property="id" value="01"/>

name是实力的名字，property为属性名称，value自然就是值了。

• getProperty指令 ：获取javaBean实例属性值

<jsp:getProperty name="name" property="id"/>

Jsp的内置对象

• application对象：web应用本身
  作用：

1.共享数据：将某个需要共享的值放到application中，就可以在可用范围内进行使用
<%
    //设置参数
    application.setAttribute("name","roobtyan");
    //获取参数
    String name = application.getAttribute("name");
%>

2.获得web应用配置参数
比如说，当前的xml文件中有如下配置参数，我要获取到它
<context-param>
    <param-name>name</param-name>
    <param-value>roobtyan</value>
</context-param>
使用的方法如下
String name = application.getInitParameter("name");

• config对象

web.xml配置文件如下：
<servlet>
    <init-param>
        <param-name>name</param-name>
        <param-value>roobtyan</param-value>
    </init-param>
</servlet>

获取方法
String name = config.getInitParameter("name")

• exception对象
  注意：exception对象只有在errorPage中才起作用，也就是说这个对象只有在异常处理页面中才能起作用。虽然jsp脚本中的java代码无需做异常处理，但是在jsp声明中的代码必须做异常处理。
• out对象
  这个对象就是用来输出内容的，和输出语法类似。

<%
    out.println("哈哈哈");
%>

• pageContext对象
  这个对象代表的是页面上下文，用于访问jsp页面间的共享数据。
  这个对象又两个常用的方法：

getAttribute(String name)：取得page范围内的name属性
getAttribute(String name,int scope)：取得指定范围内的属性值，scope有如下常量
    PageContext.PAGE_SCOPE:page内（值：1）
    PageContext.SESSION_SCOPE:session内（值：3）
    PageContext.REQUEST_SCOPE:request内（值：2）
    PageContext.APPLICATION_SCOPE:application内（值：4）
//将变量放入指定内容内
setAttribute(String name,value,scope)
//默认存放在page中
setAttribute(String name,value)

• request对象

常用方法：
String getParameter(String paramName):获取请求参数的值
Map getParameter():获取所有请求参数的名称和值
Enumeration getParameterNames():获取所有请求参数名称组成的对象
String[] getParameterValues(String name):获取name的所有值，如果又多个值的话

//请求头相关的方法
String getHeader(String name):获取请求头的值
Enumeration<String> getHeaderNames():获取所有请求头的鸣横
Enumeration<String> getHeaders(String name):获取指定请求头的多个值
int getIntHeader(String name):获取指定请求头的值，并转换成整数值

• response对象
  作用如下

1.生成非字符响应：使用相关的类生成一张图片等
2.重定向：
    response.sendRedirect("roobtyan.jsp");
    将页面重定向到roobtyan.jsp中
注意：重定向和转发是有一定的区别的-->
    转发操作依然是一次请求，而重定向是二次请求
    转发操作所有的原页面的数据、参数等都存在，而重定向这些参数都会消失
    转发地址栏的URL不变，而重定向连URL都会改变
3.增加Cookie
//增加Cookie
Cookie c = new Cookie("name","roobtyan");
c.setMaxAge(24*3600);//设置Cookie存在的周期，不设置的话，关闭浏览器cookie就没了
reponse.addCookie(c);

//获取Cookie
Cookie[] cookies = request.getCookie();

• session对象
  通过我上面的介绍，可以看到，不论是request还是response、page等，都有可能会无法使用，而session解决了这个问题：在多个页面使用同一个变量
  session对象依然是使用键值对的方式存储的。

//存储方法
session.setAttribute("name",roobtyan);
//获取方法
session.getAttribute("name");

结语

我这一节要介绍的部分就这么多，其实JSP中还有一部分内容叫做自定义标签，由于现阶段并不怎么用，所以这部分内容就暂时不介绍了，有兴趣的小伙伴可以搜索一下。当然，还有一个使用jsp过程中常用的标签库，就是sun公司推出的jstl，这套库非常的强大，应该是属于必学的内容，就是一个简单的使用，教程链接在这里：https://www.yiibai.com/jsp/jstl.html

感谢您的阅读，欢迎指正博客中存在的问题，也可以跟我联系，一起进步，一起交流！

微信公众号：进击的程序狗
邮箱：roobtyan@outlook.com
个人博客：http://roobtyan.cn
扫描下面的二维码关注我吧，你将收获到意想不到的东西哟……
给大家准备了一份非常棒的JAVA的视频教程，从JAVA基础一直到JAVAWEB，还有非常强大的项目实战。
就在我的微信公众号里，回复java就可查看，免费的呦！

前言

本文是工信部信通院《数据流通关键技术白皮书》解读之二。
实现数据流通又不泄露用户隐私信息，是白皮书的目标。实现这个目标，手段有多种，比如安全多方计算，区块链等都是技术手段之一。
由于目前还在技术选型阶段，所以据我了解，至少存在如下的技术路线：

1. TEE可信执行环境。纯硬件方案。这方面比较有代表性的，比如微信指纹支付

1. 支付宝、微信的后台系统不会保存用户支付指纹（用户隐私信息明文只存在于TEE中，像指纹那样，其实数据量也不大）；TEE根证书方案按微信方案来
2. 用户隐私数据灌装，验证指纹和密码，根据可信证书链灌装（灌装身份证信息，传输过程密文，TEE中是明文）
   算法灌装
3. 指纹支付时，先调用iOS / Android系统api，校验用户指纹是否正确，如果正确，通过支付接口，上送本地缓存的token。
   数据是收集起来批量处理时效率比较高，但是广泛收集用户数据又存在泄露隐私的问题，所以近年来边缘计算兴起，整个计算工作干脆下沉到用户侧，明文只能认证后写入TEE环境，不能被反向读出，因为计算都在用户本地完成，过程中不必收集用户隐私数据，所以当然不会泄露隐私。不过这种模式下必然要求人手一个TEE，估计计算能力和存储容量都不会太强。

这个方案特点是“用户信息仅保存在本地，在本地明文计算，网络只传输计算结果”。

2. 硬件+软件方案

这个似乎是公信宝的路线。前一个方案可以过程中不收集用户隐私数据，但是该方案中需要收集，这不仅仅是数据批量处理提升效率，更重要的是前一个方案只适用于单个用户的数据计算，不适用于多方数据的融合计算。以风控为例子，前者只适用于有了风控模型后，核验个人风险，但是问题是模型从哪里来？还是需要用户数据来训练，换而言之，前者不管训练，而后者把训练也管起来了。
企业收集后的用户隐私加密数据，放到企业级TEE的黑箱子里（可以是云硬件+docker软件，只是这个软件要认证过，只支持有限的操作集合，加密隐私数据只能写入，不能被读出）。
注意，各方的私钥是存入企业级TEE的黑箱子的，只是不能被读出。
加假如这个TEE软件是docker来实现的话，建议加上一个区块链，TEE内部操作都记入区块链，比如启动的镜像是可信第三方安全认证过的，TEE的密码学操作，数据hash，数据销毁等步骤记下简单的日志，日志写入区块链。
这个方案特点是“用户信息加密后出库保存TEE异地，在异地明文计算，网络只传输计算结果”。

3. 同态加密，零知识证明方案

参考之前写的：
《数据流通关键技术》之一：同态加密.md
《数据流通关键技术》之三：零知识证明.md
这个方案特点是“用户信息加密后出库保存异地，在异地密文计算，网络只传输计算结果”。
缺点是效率太低，目前无法商用。

4. 安全多方计算，本文的主角

具体介绍：

安全多方计算（Secure Multi-Party Computation）的研究主要是针对无可信第三方的情况下, 如何安全地计算一个约定函数的问题. 安全多方计算在电子选举、电子投票、电子拍卖、秘密共享、门限签名等场景中有着重要的作用.
一个安全多方计算协议，如果对于拥有无限计算能力攻击者而言是安全的，则称作是信息论安全的或无条件安全的；如果对于拥有多项式计算能力的攻击者是安全的，则称为是密码学安全的或条件安全的。已有的结果证明了在无条件安全模型下，当且仅当恶意参与者的人数少于总人数的1/3时，安全的方案才存在。而在条件安全模型下，当且仅当恶意参与者的人数少于总人数的一半时，安全的方案才存在。

这个方案特点是“用户信息仅保存在本地，分布式密文计算，网络传输加密的过程数据和计算结果”。
效率目前已经提升到可以商用的程度了。

安全多方计算(sMPC) Secure Multi-party Computation

安全多方计算从入门到精通：MPC简介&JUGO平台

性能提升趋势（商业化所最关注的效率问题）：

MPC计算速度提升很快

目前来看，MPC在多种技术中脱颖而出，主要是因为快且安全， TEE快但是不安全需要信任，其他两种虽然安全但是很慢

如果上面那个介绍不清楚，还是看如下技术人员的描述吧：
github上安全多方计算的资料收集

理论基础：根本不是姚的，而是老外的

• 非拜占庭行为，Shamir的多项式秘密共享是多方计算的基石
• 拜占庭行为，Chor、Goldwasser、Micali和Awerbuch的可验证秘密共享