TDLTE eNB MAC与PHY接口方案.doc

《TDLTE eNB MAC与PHY接口方案.doc》由会员分享，可在线阅读，更多相关《TDLTE eNB MAC与PHY接口方案.doc（89页珍藏版）》请在三一办公上搜索。

1、ContentsIntroduction21.1 LTE21.2 L1 API22 L1 API Procedures32.1 Configuration Procedures42.1.1 Initialization52.1.2 Termination92.1.3 Restart92.1.4 Reset102.1.5 Reconfigure102.1.6 Query112.1.7 Notification122.2 Subframe Procedures122.2.1 SUBFRAME Signal132.2.2 SFN/SF Synchronization142.2.3 API Messa

2、ge Order182.2.4 Semi-Static Information212.2.5 Uplink HARQ Signalling222.2.6 Downlink222.2.7Uplink282.2.8Error Sequences343L1 API Messages353.1 General Message Format353.2Configuration Messages363.2.1 PARAM373.2.2 CONFIG393.2.3 Configuration TLVs423.2.4 START473.2.5 STOP483.2.6 UE CONFIG483.2.7 UE R

3、ELEASE523.2.8 PHY Notifications533.3 Subframe Messages553.3.1 SUBFRAME553.3.2 Downlink Data803.3.3 Uplink Data813.4 Error Codes893.4.1 Sub Error Codes89IntroductionThis document describes an Application Programming Interface (API) which defines the interface between LTE L2/L3 software and L1 PHY. Sp

4、ecifically, this L1 API defines both P5 and P7 of the Femto Forum LTE FAPI. The LTE standard 3 has been designed to support both TDD and FDD deployments. The LTE L1 API, described in this document, also supports TDD and FDD modes. Features which are specific to only TDD, or FDD, are clearly highligh

5、ted. This document is divided into two sections. The first section provides a description of typical procedures which will occur between the L1 and L2/L3 software. The second section provides the definition of the L1 API messages.1.1 LTELTE is standardized by 3GPP (http:/www.3gpp.org) and designed a

6、s an evolution to the current WCDMA wireless network, which is in widespread use today. A critical requirement of LTE is the capability of supporting high data rates (300Mbps), and many aspects of the LTE network have been designed specifically to support high data rates and low latency.Figure 1 sho

7、ws the architecture of a LTE network. It consists of only two elements; the Evolved Pack Core (EPC) and the E-UTRAN Node B (eNB). The LTE L1 API resides within the eNB element. The two standardized interfaces in a LTE network are called S1 and X2. The L1 is not involved in either of these interfaces

8、, and both are out of scope for this document.Figure 1: LTE Architecture1.2 L1 APIThe L1 API, defined in this document, resides within the eNB component. The functionality of an eNB is shown in Figure 2 and Figure 3. In both Figures the location of the L1 API is highlighted.Figure 2 shows the protoc

9、ol model for the eNB defined in the E-UTRAN architectural standard 4. It highlights the separation of control- and data-plane information, which is maintained throughout the LTE network. Both control- and data-plane information is passed through the L1 API, however, each API message contains either

10、control- or data-plane information, but never both.Figure 2: E-UTRAN protocol modelFigure 3 provides an example of how the different L2/L3 protocol layers will interact with the L1 API. In this example, a PHY control entity is responsible for configuration procedures (P5). The MAC layer is responsib

11、le for the exchange of data-plane messages with the PHY (P7). The PHY configuration sent over the P5 interface may be determined using SON techniques, information model parameters sent from the HeMS 11, or a combination of both methods.Figure 3: L1 API Interactions2 L1 API ProceduresThis section giv

12、es an overview of the procedures which use the L1 API. These procedures are split into two groups, namely, configuration procedures and subframe procedures. Configuration procedures handle the management of the PHY layer and are expected to occur infrequently. Subframe procedures determine the struc

13、ture of each 1ms subframe and operate with a 1ms periodicity.API接口处理分为配置管理和子帧处理两部分，配置部分对物理层的参数进行配置，子帧部分每1ms子帧周期进行相应的处理。2.1 Configuration ProceduresThe configuration procedures supported by the L1 API are: Initialization Termination Restart Reset Error notificationThese procedures will move the PHY l

14、ayer through the IDLE, CONFIGURED and RUNNING states, as shown in Figure 4. A list of the L1 API configuration messages which are valid in each state is given in Table 1.Figure 4: PHY layer state transactions on L1 API configuration messagesTable 1: L1 API configuration messages valid in each PHY st

15、ate2.1.1 InitializationThe initialization procedure moves the PHY from the IDLE state to the RUNNING state, via the CONFIGURED state. An overview of this procedure is given in Figure 5, the different stages are: The PARAM message exchange procedure The CONFIG message exchange procedure The START mes

16、sage exchange procedureThe initialization procedure is completed when the PHY sends the L2/L3 software a SUBFRAME.indication message. The remainder of this section describes the PARAM, CONFIG and START message exchange procedures.Figure 5: Initialization procedureThe PARAM message exchange procedure

17、 is shown in Figure 6. Its purpose is to allow the L2/L3 software to collect information about the PHY configuration and current state. The information returned by the PHY depends on its state, and is described in Table 2. The PARAM message exchange is optional.Table 2: Information returned by the P

18、HY during a PARAM message exchangeFrom Figure 6 it can be seen that the PARAM message exchange procedure is initiated by the L2/L3 software sending a PARAM.request message to the PHY. It is recommended that the L2/L3 software starts a guard timer to wait for the response from the PHY. If the PHY is

19、operating correctly it will return a PARAM.response message. In the IDLE and CONFIGURED states this message will include the current PHY state and a list of configuration information, as described in Table 2. In the RUNNING state this message will indicate an INVALID_STATE error, to determine the PH

20、Y capabilities it must be moved to the CONFIGURED state using the termination procedure. If the guard timer expires before the PHY responds this indicates the PHY is not operating correctly. This must be rectified before further L1 API commands are used; the rectification method is outside the scope

21、 of this document. The CONFIG message exchange procedure is shown in Figure 7. Its purpose is to allow the L2/L3 software to configure the PHY. It can be used when the PHY is in any state. The procedure has slight differences depending on the PHY state, for clarity each case is described separately.

22、 If the PHY is in the IDLE state the CONFIG.request message, sent by the L2/L3 software, must include all mandatory TLVs. The mandatory TLVs are highlighted later in Section 3.2.2.1. If all mandatory TLVs are included, and set to values supported by the PHY, L1 will return a CONFIG.response message

23、indicating it is successfully configured and has moved to the CONFIGURED state. If the CONFIG.request message has missing mandatory TLVs, invalid TLVs, or unsupported TLVs, the PHY will return a CONFIG.response message indicating an incorrect configuration. In this case, it will remain in the IDLE s

24、tate and all received TLVs will be ignored.Figure 6: PARAM message exchangeIf the PHY is in the CONFIGURED state the CONFIG.request message, sent by the L2/L3 software, may include only the TLVs that are required to change the PHY to a new configuration. If the PHY supports these new values, it will

25、 return a CONFIG.response message indicating it has been successfully configured. However, if the CONFIG.request message includes invalid TLVs, or unsupported TLVs, the PHY will return a CONFIG.response message indicating an incorrect configuration. In this case all received TLVs will be ignored and

26、 the PHY will continue with its previous configuration. In both cases, if the PHY receives a CONFIG.request while in the CONFIGURED state it will remain in the CONFIGURED state.If the PHY is in the RUNNING state then a limited subset of CONFIG TLVs may be sent in a CONFIG.request message. The permit

27、ted TLVs are highlighted later in Section 3.2.2.1. If the CONFIG.request message has invalid TLVs, or TLVs which must not be reconfigured in the RUNNING state, the PHY will return a CONFIG.response message indicating an incorrect configuration. In this case, it will remain in the RUNNING state and a

28、ll received TLVs will be ignored.Figure 7: CONFIG message exchangeThe START message exchange procedure is shown in Figure 8. Its purpose is to instruct a configured PHY to start transmitting as an eNB. The L2/L3 software initiates this procedure by sending a START.request message to the PHY. If the

29、PHY is in the CONFIGURED state, it will issue a SUBFRAME indication. After the PHY has sent its first SUBFRAME.indication message it enters the RUNNING state. If the PHY receives a START.request in either the IDLE or RUNNING state it will return an ERROR.indication including an INVALID_STATE error.F

30、igure 8: START message exchange2.1.2 TerminationThe termination procedure is used to move the PHY from the RUNNING state to the CONFIGURED state. This stops the PHY transmitting as an eNB. The termination procedure is shown in Figure 9 and initiated by the L2/L3 software sending a STOP.request messa

31、ge. If the STOP.request message is received by the PHY while operating in the RUNNING state, it will stop all TX and RX operations and return to the CONFIGURED state. When the PHY has completed its stop procedure a STOP.indication message is sent to the L2/L3 software. If the STOP.request message wa

32、s received by the PHY while in the IDLE or CONFIGURED state, it will return an ERROR.indication message including an INVALID_STATE error. However, in this case the PHY was already stopped.Figure 9: Termination procedure2.1.3 RestartThe restart procedure is shown in Figure 10. It can be used by the L

33、2/L3 software when it needs to stop transmitting, but later wants to restart transmission using the same configuration. To complete this procedure the L2/L3 software can follow the STOP message exchange shown in Figure 9. This moves the PHY to the CONFIGURED state. To restart transmission it should

34、follow the START message exchange, shown in Figure 8, moving the PHY back to the RUNNING state.Figure 10: Restart procedure2.1.4 ResetThe reset procedure is shown in Figure 11. This procedure is used when the L2/L3 software wants to return the PHY to the IDLE state. This can only be achieved by term

35、inating the PHY (as shown in Figure 9) and then resetting the PHY. The method for resetting the PHY will be implementation specific and outside the scope of this document.Figure 11: Reset procedure2.1.5 ReconfigureTwo methods of reconfiguration are supported by the PHY. A major reconfiguration where

36、 the PHY is stopped, and a minor reconfiguration where the PHY continues running. The major reconfigure procedure is shown in Figure 12. It is used when the L2/L3 software wants to make significant changes to the configuration of the PHY. The STOP message exchange, shown in Figure 9, is followed to

37、halt the PHY and move it to the CONFIGURED state. The CONFIG message exchange, shown in Figure 7, is used to reconfigure the PHY. Finally, the START message exchange, shown in Figure 8, is followed to start the PHY and return it to the RUNNING state.Figure 12: Major reconfiguration procedureThe mino

38、r reconfiguration procedure is shown in Figure 13. It is typically used in conjunction with a RRC system information update. In the subframe where the L2/L3 software requires the configuration change it sends the CONFIG.request message to the PHY. Only a limited subset of CONFIG TLVs may be sent, th

39、ese are highlighted later in Section 3.2.2.1. TLVs included in the CONFIG.request message for subframe N will be applied at the SFN/SF given in the CONFIG.request message. Reconfiguring the PHY while in the RUNNING state has a further restriction, the CONFIG.request message must be sent before the D

40、L_CONFIG.request and UL_CONFIG.request message.Figure 13: Minor reconfigure procedure2.1.6 QueryThe query procedure is shown in Figure 14. It is used by the L2/L3 software to determine the configuration and operational status of the PHY. The PARAM message exchange, shown in Figure 6, is used. This s

41、ignalling sequence can be followed when the PHY is stopped, in the IDLE state and, optionally, the CONFIGURED state.Figure 14: Query procedure2.1.7 NotificationThe notification procedure is shown in Figure 15. The PHY sends a notification message when it has an event of interest for the L2/L3 softwa

42、re. Currently, there is one notification message called ERROR.indication. The ERROR.indication message has already been mentioned in multiple procedures. It is used by the PHY to indicate that the L2/L3 software has sent invalid information to the PHY.Figure 15: Notification procedures2.2 Subframe P

43、roceduresThe subframe procedures have two purposes. Firstly, they are used to control the DL and UL frame structures. Secondly, they are used to transfer the subframe data between the L2/L3 software and PHY. The subframe procedures supported by the L1 API are: Transmission of a 1ms SUBFRAME message

44、Synchronization of SFN/SF between the L2/L3 software and PHY Transmission of the BCH transport channel Transmission of the PCH transport channel Transmission of the DL-SCH transport channel and reception of ACK/NACK response Transmission of the MCH transport channel Reception of the RACH transport c

45、hannel Reception of the UL-SCH transport channel and transmission of ACK/NACK response Reception of the sounding reference signal Reception of CQI and RI reporting Reception of scheduling request information 2.2.1 SUBFRAME SignalA SUBFRAME.indication message is sent from the PHY, to the L2/L3 softwa

46、re, indicating the start of a 1ms subframe. The periodicity of the SUBFRAME.indication message for TDD (frame structure 2) is shown in Figure 16 and Figure 17. In TDD two frame structures are possible, one with 5ms switch points and one with 10ms switch points 3. The SUBFRAME.indication message is g

47、enerated for every subframe (DL or UL).Figure 16: SUBFRAME signal for TDD using 5ms switch pointsFigure 17: SUBFRAME signal for TDD using 10ms switch pointThe periodicity of the SUBFRAME.indication message for FDD (frame structure 1) is shown in Figure 18. The subframe indication is generated for ev

48、ery DL subframe.Figure 18: SUBFRAME signal for FDD2.2.2 SFN/SF SynchronizationThe SFN/SF synchronization procedure is used to maintain a consistent SFN/SF value between the L2/L3 software and PHY. Maintaining this synchronization is important since different subframes have different structures, and in TDD subframes are either downlink or uplink. Two options are provided by the L1 API; the first option configures the PHY to use the SFN/SF value