实例介绍
【实例简介】
做NS3仿真lte的话可以参考一下，非常不错的文档
CONTENTS 1 Design documentation 1.1 Overall Architecture 1.2 LTE Model 1. 3 EPC Model “· 4 1.4 Description of the components 8 15 MAC 8 1. 6 RLC and PDCP 1.7 RRC 18 1. 8 PhY 19 1.9 Channel and Propagation 19 1. 10 Helpers 2 User Documentation 27 2.1 Back ground 27 2.2 Usage overview 2.3 Basic simulation program 7 2.4 Configuration of LTE model parameters 29 2.5 Simulation Output 29 2.6 Fading Trace Usage 31 2.7 Buildings mobility model 2.8 Evolved Packet Core (EPC) 36 2.9 Further Readin 37 3 Testing documentation 3.1 Overview 39 3.2 Description of the test suites 39 4 Profiling Documentation 4.1 Overview and objectives 4.2 Framework description 47 4.3 Result Biblic h 5 CHAPTER ONE DESIGN DOCUMENTATION 1.1 Overall Architecture The overall architecture of the lena simulation model is depicted in the figure Overall architecture of the LtE-EPc simulation model. There are two main conmponents the lte model. This model includes the ltE Radio protocol stack (RRC, PDCP, RlC, MAC, PhY). These entities reside entirely within the ue and the enb nodes the ePC Model. This models includes core network interfaces, protocols and entities. These entities and proto- cols reside within the SGw, PGW and MME nodes, and partially within the eNB nodes Each component of the overall architecture is explained in detail in the following subsections UE EPC model eNB UE Gi interface LTE nternet model Sl- interfa SGW/PGW Figure 1.1: Overall architecture of the LtE-epc simulation model 1.2 LTE Model 1.2.1 Design Criteria The LtE model has been designed to support the evaluation of the following aspects of lTE systems LTE Simulator Documentation Release M4 Radio resource management QoS-aware Packet Scheduling Inter-cell Interference Coordination Dynamic spectrum Access In order to model lte systems to a level of detail that is sufficient to allow a correct evaluation of the above mentioned aspects, the following requirements have been considered I. At the radio level, the granularity of the model should be at least that of the resource Block(rB). In fact this is the fundamental unit being used for resource allocation. Without this minimum level of granularity, it is not possible to model accurately packet scheduling and inter-cell-interference. The reason is that, since packet scheduling is done on a per-RB basis, an enB might transmit on a subset only of all the available rBs, hence interfering with other eNBs only on those rBs where it is trasmitting. Note that this requirement rules out the adoption of a system lever simulation approach, which evaluates resource allocation only at the granularity of call/bearer establishment 2. The simulator should scale up to tens of eNBs and hundreds of User Equipments (UEs). This rules out the use of a link level simulator, i.e., a simulator whose radio interface is modeled with a granularity up to the symbol level This is because to have a symbol level model it is necessary to implement all the PhY layer signal processin Those huge computational complexity severely limits simulation. In fact, link-level simulators are normally limited to a single enb and one or a few ues 3. It should be possible within the simulation to configure different cells so that they use different carrier frequen cies and system bandwidths. The band width used by different cells should be allowed to overlap, in order to support dynamic spectrum licensing solutions such as those described in in-citeofcom26GHz, Real wireless The calculation of interference should handle appropriately this case 4. To be more representative of the lte standard, as well as to be as close as possible to real-world implemen tations, the simulator should support the mac Scheduler APi published by the Femto Forum [FFAPI This interface is expected to be used by femtocell manufacturers for the implementation of scheduling and radio Resource Management (RRM)algorithms. By introducing support for this interface in the simulator, we make it possible for LtE equipment vendors and operators to test in a simulative environment exactly the same algo rithms that would be deployed in a real system The te simulation module should contain its own implementation of the APl defined in FFAPl] Neither binary nor data structure compatibility with vendor-specific implementations of the same interface are expected hence a compatibility layer should be interposed whenever a vendor-specific mac scheduler is to be used with the simulator. This requirement is necessary to allow the simulator to be independent from vendor-specific implementations of this interface specification. We note that [FFAPI is a logical specification only, and its implementation(e. g, translation to some specific programming language)is left to the vendors 1.2.2 Architecture For the sake of an easier explanation, we further divide the lte model in two separate parts, which are described in the following The first part is the lower Lte radio protocol stack, which is represented in the figures Lower LTE radio protocol stack architecture for the eNB and Lower LTE radio protocol stack architecture for the cE, which deal respectively with the eNB and the ue The lte lower radio stack model includes in particular the PhY and the MAc layers; additionally, also the scheduler s included (which is commonly associated with the mac layer). The most important difference between the eNB and the ue is the presence of the Scheduler in the enB, which is in charge of assigning radio resources to all UEs and Radio bearers both in uplink and downlink. This component is not present within the Ue Chapter 1. Design Documentation LTE Simulator Documentation Release M4 Lte EnbRrc SteRIc LteEnb CmacSap LteMacsa FfCschedsap into irasport Channels Lteenbmac FfSchedsap lte c rum FfMacscheduler Radio Resource Allocation Scheduling Adaptive Modulation and Coding LteEnbPhy Sap Specificatol == handling of frames/ subframes simulation of signal prccessing LteEnbph interference calculation cQ calculation StartTx StartRX O UEs'DL SpectrumPhy LteSpectrumPhy I LteSpectrum Phy UEs′ UL SpectrumPhy StartTX o StartRX O StartRx O StartT×() SpectrumChannel SpectrumChannel Downlink Uplink Figure 1. 2: Lower LtE radio protocol stack archilecture for the eNB LteUerrc SteRIc LteUeCmac sap LteMacSap ne instance per active Radio Bearer ing of Logical Ch into Trasport Channels LteUeMac LteEnbPhy sa handling of frames/ subframes simulation of signal processing LteUePhy interference calculation CQI calculation StartT×0 StartS i eNB'S DL SpectrumPhy LteSpectrum Phy LteSpectrum Phy UES' UL SpectrumPhy 个 StartRX O StartRX O StartTx O StartT×() Spectrumchannel Spectrum Channel Downlink Uplink Figure 1.3: Lower LTE radio protocol stack architecture for the UE 12. TE Model 3 LTE Simulator Documentation Release M4 The second part is the upper Lte radio stack, which is represented in the figure Architecture of the upper lte radio k Send o m rx callback o te[Enb, Ue] Send o Receive o Lte[Enb, Ue]Rrc LtePdco sauSe Ltepdcp ●● LtePdcp LteRlcsapUser instance LteRlcSapProvide SteRIc ●●● Steric LteMacsapUser LteMacsapUse LteMacsapprovide IEnb, Ue]Mac Figure 1. 4: Architecture of the upper LTE radio stack This part includes the rrC, PdCp and rlC protocols. The architecture in this case is very similar between the eNB and the UE: in fact, in both cases there is a single MAC instance and a single rrc instance, that work together with pairs of rlC and PDCP instances(one RlC and one PDCp instance per radio bearer) We note that in the current version of the simulator only the data plane of the upper lte radio protocol stack is modeled accurately; in particular, the rlc and Pdcp protocol are implemented with actual protocol headers that match those specified by the 3GPP standard. On the other hand, the functionality of the control plane(which for the upper LTE radio protocol stack involves mainly the rrC) is modeled in a significantly simplified fashion 1.3 EPC Model The EPC model provides means for the simulation of end-to-end IP connectivity over the Lte model. In particular, it supports for the interconnection of multiple UEs to the internet, via a radio access network of multiple enBs connected to a single SGW/PGW node. This network topology is depicted in Figure Overall architecture of the LTE-EPC simulation model 1.3.1 Design Criteria The following design choices have been made for the EPC model the only Packet Data Network(PDN) type supported is IPv4 2. the SGW and PGw functional entities are implemented within a single node, hich is hence referred to as the SGW/PGW node Chapter 1. Design Documentation LTE Simulator Documentation Release M4 3. scenarios with inter-SGW mobility are not of interests. Hence, a single sGw/PGw node will be present in all simulations scenarios 4. a clear use case for the ePC model is to accurately simulate the end-to-end performance of realistic applications Hence, it should be possible to use with the EPC model any regular ns-3 application working on top of TCP or UDP 5. another clear use case is the simulation of network topologies with the presence of multiple eNBS, some of which might be equipped with a backhaul connection with limited capabilities. In order to simulate such scenarios accurately, the user data plane protocols being used between the eNBs and the sGW/PGw should be modeled accuratel 6. it should be possible for a single UE Lo use different application with different Qos profiles. Hence, multiple EPS bearers should be supported for each UE. This includes the necessary classification of TCP/UDP traffic over ip done at the ue in the uplink and at the pg w in the downlink 7. the focus of the EPC model is mainly on the EPC data plane. The accurate Imodeling of the EPC control plane is, for the time being, not a requirement; hence, the necessary control plane interactions can be modeled in a simplified way by leveraging on direct interaction among the different simulation objects via the provided helper objects 8. the focus of the model is on simulations of active users in ECM connected mode. Hence, all the functionality that is only relevant for ECM idle mode(in particular, tracking area update and paging) are not modeled at all 9. while handover support is not a current requirement, it is planned to be considered in the near future. Hence, the management of EPs bearers by the eNBs and the sGw/PGw should be implemented in such a way that it can be re-used when handover support is eventually added 1.3.2 Architecture The focus of the ePC model is currently on the epc data plane To understand the architecture of this model, we first look at Figure LTE-EPC data plane protocol stack representation of the end-to-end LtE-EPC protocol stack, as it is implemented in the simulator. From the figure, it is evident that the biggest simplification introduced in the EPC model for the data plane is the inclusion of the Sgw and Pgw functionality within a single sg w/Pgw node, which removes the need for the s 5 or s& interfaces specified by 3GPP. On the other hand, for both the sl-U protocol stack and the lte radio protocol stack all the protocol layers specified by 3GPP are present From the figure, it is evident that there are two different layers of IP networking. The first one is the end-to-end layer, which provides end-to-end connectivity to the users; this layers involves the UEs, the PGw and the remote host (including eventual internet routers and hosts in between), but does not involve the eNB. By default, UEs are assigned a public IPv4 address in the 7.0.0.0/8 network, and the Pgw gets the address 7.0.0.1, which is used by all UEs as the gateway to reach the internet. The second layer of IP networking is the ePC local area network. This involves all enB nodes and the sg w/pg w node. This network is formed by a set of point-to-point links which connect each eNB with the SGW/PGW node; thus, the so w/PG w has a separate point-to-point device which provides connectivity to a single eNB. By defaull, a 10.x.y. Z/30 subnet is assigned to each point-to-point link As specified by 3GPP, the end-to-end IP communications is tunneled over the local EPC IP network usin GTP/UDP/IP. In the following. we explain how this tunneling is implemented in the EPC model. The explanation is done by discussing the end-to-end fow of data packets To begin with, we consider the case of the downlink, which is depicted in Figure Data flow in the dowlink between the internet and the UE Downlink Ipv4 packets are generated from a generic remote host, and addressed to one of the ue device. Internet routing will take care of forwarding the packet to the generic Net Device of the SGW/PGw node which is connected to the internet(this is the Gi interface according to 3GPP terminology). The SGw/PGW has a virtualNet Device which is assigned the gateway IP address of the UE subnet; hence, static routing rules will cause the incoming packet from 1.3, EPC Model LTE Simulator Documentation Release M4 UE eNB SGW/PGW /emote host APP end-to-end application APP TCP/UDP end-to-end TCP/UDP socket connection TCP/UDP end-to-end IP connection P P PDCP PDCP E- GTP GTP ■■■■■■■ RLO RLC UDP UDP MAC MAC P PHY PHY I L LTE Radio protocol stack Sl-U protocol stack ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Figure 1. 5: LTE-EPC data plane protocol stack UE node eNB node SGW/PGW node Il remve GTP header extract TE. application | EpcEnbApplication地 EpcSgw PgwApplication 2) det mine sh) tao by tP ditching TP- he bucket uul-yurel wLu I acket TP +TP/JDP- AP compositio 4 sake t to UOp sock aderuskud IPv4 : L pp IPv4 IPV4 Ir addres lacal dative local salivary internet Steve I LteEnb S1-U P2p SI-U P2p TUN Virtual NetDevice NetDevice NetDevice NetDevice NetDevice NetDevice fany kind) IP pa: ke: tom the internet acket sent over the LTE Fadio Enar the 51-L campsite Figure 1. 6: Data flow in the dowlink between the internet and the uE Chapter 1. Design Documentation 【实例截图】
【核心代码】
做NS3仿真lte的话可以参考一下，非常不错的文档
CONTENTS 1 Design documentation 1.1 Overall Architecture 1.2 LTE Model 1. 3 EPC Model “· 4 1.4 Description of the components 8 15 MAC 8 1. 6 RLC and PDCP 1.7 RRC 18 1. 8 PhY 19 1.9 Channel and Propagation 19 1. 10 Helpers 2 User Documentation 27 2.1 Back ground 27 2.2 Usage overview 2.3 Basic simulation program 7 2.4 Configuration of LTE model parameters 29 2.5 Simulation Output 29 2.6 Fading Trace Usage 31 2.7 Buildings mobility model 2.8 Evolved Packet Core (EPC) 36 2.9 Further Readin 37 3 Testing documentation 3.1 Overview 39 3.2 Description of the test suites 39 4 Profiling Documentation 4.1 Overview and objectives 4.2 Framework description 47 4.3 Result Biblic h 5 CHAPTER ONE DESIGN DOCUMENTATION 1.1 Overall Architecture The overall architecture of the lena simulation model is depicted in the figure Overall architecture of the LtE-EPc simulation model. There are two main conmponents the lte model. This model includes the ltE Radio protocol stack (RRC, PDCP, RlC, MAC, PhY). These entities reside entirely within the ue and the enb nodes the ePC Model. This models includes core network interfaces, protocols and entities. These entities and proto- cols reside within the SGw, PGW and MME nodes, and partially within the eNB nodes Each component of the overall architecture is explained in detail in the following subsections UE EPC model eNB UE Gi interface LTE nternet model Sl- interfa SGW/PGW Figure 1.1: Overall architecture of the LtE-epc simulation model 1.2 LTE Model 1.2.1 Design Criteria The LtE model has been designed to support the evaluation of the following aspects of lTE systems LTE Simulator Documentation Release M4 Radio resource management QoS-aware Packet Scheduling Inter-cell Interference Coordination Dynamic spectrum Access In order to model lte systems to a level of detail that is sufficient to allow a correct evaluation of the above mentioned aspects, the following requirements have been considered I. At the radio level, the granularity of the model should be at least that of the resource Block(rB). In fact this is the fundamental unit being used for resource allocation. Without this minimum level of granularity, it is not possible to model accurately packet scheduling and inter-cell-interference. The reason is that, since packet scheduling is done on a per-RB basis, an enB might transmit on a subset only of all the available rBs, hence interfering with other eNBs only on those rBs where it is trasmitting. Note that this requirement rules out the adoption of a system lever simulation approach, which evaluates resource allocation only at the granularity of call/bearer establishment 2. The simulator should scale up to tens of eNBs and hundreds of User Equipments (UEs). This rules out the use of a link level simulator, i.e., a simulator whose radio interface is modeled with a granularity up to the symbol level This is because to have a symbol level model it is necessary to implement all the PhY layer signal processin Those huge computational complexity severely limits simulation. In fact, link-level simulators are normally limited to a single enb and one or a few ues 3. It should be possible within the simulation to configure different cells so that they use different carrier frequen cies and system bandwidths. The band width used by different cells should be allowed to overlap, in order to support dynamic spectrum licensing solutions such as those described in in-citeofcom26GHz, Real wireless The calculation of interference should handle appropriately this case 4. To be more representative of the lte standard, as well as to be as close as possible to real-world implemen tations, the simulator should support the mac Scheduler APi published by the Femto Forum [FFAPI This interface is expected to be used by femtocell manufacturers for the implementation of scheduling and radio Resource Management (RRM)algorithms. By introducing support for this interface in the simulator, we make it possible for LtE equipment vendors and operators to test in a simulative environment exactly the same algo rithms that would be deployed in a real system The te simulation module should contain its own implementation of the APl defined in FFAPl] Neither binary nor data structure compatibility with vendor-specific implementations of the same interface are expected hence a compatibility layer should be interposed whenever a vendor-specific mac scheduler is to be used with the simulator. This requirement is necessary to allow the simulator to be independent from vendor-specific implementations of this interface specification. We note that [FFAPI is a logical specification only, and its implementation(e. g, translation to some specific programming language)is left to the vendors 1.2.2 Architecture For the sake of an easier explanation, we further divide the lte model in two separate parts, which are described in the following The first part is the lower Lte radio protocol stack, which is represented in the figures Lower LTE radio protocol stack architecture for the eNB and Lower LTE radio protocol stack architecture for the cE, which deal respectively with the eNB and the ue The lte lower radio stack model includes in particular the PhY and the MAc layers; additionally, also the scheduler s included (which is commonly associated with the mac layer). The most important difference between the eNB and the ue is the presence of the Scheduler in the enB, which is in charge of assigning radio resources to all UEs and Radio bearers both in uplink and downlink. This component is not present within the Ue Chapter 1. Design Documentation LTE Simulator Documentation Release M4 Lte EnbRrc SteRIc LteEnb CmacSap LteMacsa FfCschedsap into irasport Channels Lteenbmac FfSchedsap lte c rum FfMacscheduler Radio Resource Allocation Scheduling Adaptive Modulation and Coding LteEnbPhy Sap Specificatol == handling of frames/ subframes simulation of signal prccessing LteEnbph interference calculation cQ calculation StartTx StartRX O UEs'DL SpectrumPhy LteSpectrumPhy I LteSpectrum Phy UEs′ UL SpectrumPhy StartTX o StartRX O StartRx O StartT×() SpectrumChannel SpectrumChannel Downlink Uplink Figure 1. 2: Lower LtE radio protocol stack archilecture for the eNB LteUerrc SteRIc LteUeCmac sap LteMacSap ne instance per active Radio Bearer ing of Logical Ch into Trasport Channels LteUeMac LteEnbPhy sa handling of frames/ subframes simulation of signal processing LteUePhy interference calculation CQI calculation StartT×0 StartS i eNB'S DL SpectrumPhy LteSpectrum Phy LteSpectrum Phy UES' UL SpectrumPhy 个 StartRX O StartRX O StartTx O StartT×() Spectrumchannel Spectrum Channel Downlink Uplink Figure 1.3: Lower LTE radio protocol stack architecture for the UE 12. TE Model 3 LTE Simulator Documentation Release M4 The second part is the upper Lte radio stack, which is represented in the figure Architecture of the upper lte radio k Send o m rx callback o te[Enb, Ue] Send o Receive o Lte[Enb, Ue]Rrc LtePdco sauSe Ltepdcp ●● LtePdcp LteRlcsapUser instance LteRlcSapProvide SteRIc ●●● Steric LteMacsapUser LteMacsapUse LteMacsapprovide IEnb, Ue]Mac Figure 1. 4: Architecture of the upper LTE radio stack This part includes the rrC, PdCp and rlC protocols. The architecture in this case is very similar between the eNB and the UE: in fact, in both cases there is a single MAC instance and a single rrc instance, that work together with pairs of rlC and PDCP instances(one RlC and one PDCp instance per radio bearer) We note that in the current version of the simulator only the data plane of the upper lte radio protocol stack is modeled accurately; in particular, the rlc and Pdcp protocol are implemented with actual protocol headers that match those specified by the 3GPP standard. On the other hand, the functionality of the control plane(which for the upper LTE radio protocol stack involves mainly the rrC) is modeled in a significantly simplified fashion 1.3 EPC Model The EPC model provides means for the simulation of end-to-end IP connectivity over the Lte model. In particular, it supports for the interconnection of multiple UEs to the internet, via a radio access network of multiple enBs connected to a single SGW/PGW node. This network topology is depicted in Figure Overall architecture of the LTE-EPC simulation model 1.3.1 Design Criteria The following design choices have been made for the EPC model the only Packet Data Network(PDN) type supported is IPv4 2. the SGW and PGw functional entities are implemented within a single node, hich is hence referred to as the SGW/PGW node Chapter 1. Design Documentation LTE Simulator Documentation Release M4 3. scenarios with inter-SGW mobility are not of interests. Hence, a single sGw/PGw node will be present in all simulations scenarios 4. a clear use case for the ePC model is to accurately simulate the end-to-end performance of realistic applications Hence, it should be possible to use with the EPC model any regular ns-3 application working on top of TCP or UDP 5. another clear use case is the simulation of network topologies with the presence of multiple eNBS, some of which might be equipped with a backhaul connection with limited capabilities. In order to simulate such scenarios accurately, the user data plane protocols being used between the eNBs and the sGW/PGw should be modeled accuratel 6. it should be possible for a single UE Lo use different application with different Qos profiles. Hence, multiple EPS bearers should be supported for each UE. This includes the necessary classification of TCP/UDP traffic over ip done at the ue in the uplink and at the pg w in the downlink 7. the focus of the EPC model is mainly on the EPC data plane. The accurate Imodeling of the EPC control plane is, for the time being, not a requirement; hence, the necessary control plane interactions can be modeled in a simplified way by leveraging on direct interaction among the different simulation objects via the provided helper objects 8. the focus of the model is on simulations of active users in ECM connected mode. Hence, all the functionality that is only relevant for ECM idle mode(in particular, tracking area update and paging) are not modeled at all 9. while handover support is not a current requirement, it is planned to be considered in the near future. Hence, the management of EPs bearers by the eNBs and the sGw/PGw should be implemented in such a way that it can be re-used when handover support is eventually added 1.3.2 Architecture The focus of the ePC model is currently on the epc data plane To understand the architecture of this model, we first look at Figure LTE-EPC data plane protocol stack representation of the end-to-end LtE-EPC protocol stack, as it is implemented in the simulator. From the figure, it is evident that the biggest simplification introduced in the EPC model for the data plane is the inclusion of the Sgw and Pgw functionality within a single sg w/Pgw node, which removes the need for the s 5 or s& interfaces specified by 3GPP. On the other hand, for both the sl-U protocol stack and the lte radio protocol stack all the protocol layers specified by 3GPP are present From the figure, it is evident that there are two different layers of IP networking. The first one is the end-to-end layer, which provides end-to-end connectivity to the users; this layers involves the UEs, the PGw and the remote host (including eventual internet routers and hosts in between), but does not involve the eNB. By default, UEs are assigned a public IPv4 address in the 7.0.0.0/8 network, and the Pgw gets the address 7.0.0.1, which is used by all UEs as the gateway to reach the internet. The second layer of IP networking is the ePC local area network. This involves all enB nodes and the sg w/pg w node. This network is formed by a set of point-to-point links which connect each eNB with the SGW/PGW node; thus, the so w/PG w has a separate point-to-point device which provides connectivity to a single eNB. By defaull, a 10.x.y. Z/30 subnet is assigned to each point-to-point link As specified by 3GPP, the end-to-end IP communications is tunneled over the local EPC IP network usin GTP/UDP/IP. In the following. we explain how this tunneling is implemented in the EPC model. The explanation is done by discussing the end-to-end fow of data packets To begin with, we consider the case of the downlink, which is depicted in Figure Data flow in the dowlink between the internet and the UE Downlink Ipv4 packets are generated from a generic remote host, and addressed to one of the ue device. Internet routing will take care of forwarding the packet to the generic Net Device of the SGW/PGw node which is connected to the internet(this is the Gi interface according to 3GPP terminology). The SGw/PGW has a virtualNet Device which is assigned the gateway IP address of the UE subnet; hence, static routing rules will cause the incoming packet from 1.3, EPC Model LTE Simulator Documentation Release M4 UE eNB SGW/PGW /emote host APP end-to-end application APP TCP/UDP end-to-end TCP/UDP socket connection TCP/UDP end-to-end IP connection P P PDCP PDCP E- GTP GTP ■■■■■■■ RLO RLC UDP UDP MAC MAC P PHY PHY I L LTE Radio protocol stack Sl-U protocol stack ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Figure 1. 5: LTE-EPC data plane protocol stack UE node eNB node SGW/PGW node Il remve GTP header extract TE. application | EpcEnbApplication地 EpcSgw PgwApplication 2) det mine sh) tao by tP ditching TP- he bucket uul-yurel wLu I acket TP +TP/JDP- AP compositio 4 sake t to UOp sock aderuskud IPv4 : L pp IPv4 IPV4 Ir addres lacal dative local salivary internet Steve I LteEnb S1-U P2p SI-U P2p TUN Virtual NetDevice NetDevice NetDevice NetDevice NetDevice NetDevice fany kind) IP pa: ke: tom the internet acket sent over the LTE Fadio Enar the 51-L campsite Figure 1. 6: Data flow in the dowlink between the internet and the uE Chapter 1. Design Documentation 【实例截图】
【核心代码】
标签：
好例子网口号：伸出你的我的手 — 分享！
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论