LTEモデル調査

用語集

–	–	–
PBCH	Physical broadcast channel
UE	User Equipment
EPC(S)	Evolved Packet Core(System)
MME	Mobility Management
SAE	System Architecture
E-UTRAN	Evolved Universal
PCFICH	Physical control format indicator channel
PDCCH	Physical downlink control channel
PHICH	Physical Hybrid ARQ Indicator Channe
PDSCH	Physical downlink shared channel
PMCH	Physical multicast channel
PUCCH	Physical uplink control channel
SR	Carries Scheduling Request
PUSCH	Physical uplink shared channel
PRACH	Physical random access channel
CQI	Channel Quality Indicator
BSR	Buffer Status Report
eNB	eNodeB evoluted NodeB	E-UTRANとも呼ばれる
RACH	Random Access Channel
SAP	Service Access Point	LTEは階層的なチャンネル構造を持つ。LTEは3種類のチャンネル種別を持つ、たとえば、「Logical」「Transport」「PhysicalCahnnel」。それぞれがServiceAccessPoint(SAP)がそれぞれのレイヤーで属している。3チャンネルは、下位レイヤーが上位レイヤーに対してサービスを提供する。
Logical Channels		Transmitとは何か。それらはMACレイヤーによって、RLCレイヤーに対してサービスを提供するために使われる。 それぞれのLogicalチャンネルは、情報の種類によって定義された物を運ぶ。LTEではそれらの2つのLgocalチャンネルカテゴリはControlChannnelとTrafficChannelに分けて利用されている。
Transport Channels		どうやって転送するか。PHYはTransportChannelを使ってMACレイヤーに対してサービスを提供する。それは、どのようにデータをむせんで運ぶかを明文化されている。
Physical Channels		Actual Transmission Each physical channel maps to a set of resource elements in the time frequency grid that carry information from upper layers. The basic entities that make a physical channel are REs and RBs. A resource element is one subcarrier by one OFDM symbol and typically this could carry one (or two with spatial multiplexing) modulated symbol(s). A resource block is a collection of resource elements and in the frequency domain this represents the smallest quanta of resources that can be allocated.
HARQ	Hybrid Automatic Rrepeat reQuest(ARQ)	HSDPAやWiMAX、LTEといった最近の通信規格で採用されている“データの誤り訂正手法”です。
LCID	Logical Channel ID
FFR	Fractional Frequency Reuse	Wifiみたいに3チャンネルを交互に使うと周波数帯域が3分の１しかつかえなくなり非効率。中心エリアでは全周波数を使い、セルの隣接する端のエリアだけ3チャンネルに分けて使う。端では遅いけど干渉しない。中心だと速いし干渉しない技術
AMC	Adaptive Modulation and channel Coding	受信レベルに応じて最適な変調方式，符号化率を選択する適応変調
PDCP	Packet Data Convergence Protocol	The PDCP is located in the Radio Protocol Stack in the UMTS and LTE Air interface on top of the RLC layer. https://en.wikipedia.org/wiki/PDCP IPパケットヘッダ圧縮、解凍、暗号化を行なう
RLC	Radio link control	layer 2 protocol used in UMTS and LTE on the Air interface. RLC is located on top of the 3GPP MAC-layer and below the PDCP-layer. The main tasks of the RLC protocol https://en.wikipedia.org/wiki/Radio_Link_Control 再送制御，重複検出，順序整列を行なう
RRC	Radio Resource Control	端末（UE）と基地局（E-UTRAN）との間の接続状態は、無線ネットワークを制御するRRC（Radio Resource Control）のアイドル状態（RRC idle）とRRC接続状態（RRC Connected）の2つで示されます。システム報知情報配信、緊急地震速報配信、ページング配信、NASメッセージ配信、ハンドオーバー制御などを行なう
X2ハンドオーバー		eNB同士で端末情報を引き取りハンドオーバーする方法
S1ハンドオーバー		eNB同士のX2が使えない場合に、コア側のS-GW経由で指示してハンドオーバーさせる方法
bearer		運ぶ」の意味で、フォーマットは違えど、どこからどこまで運ばれるデータという意味で使われている。ただしRadioBearerと言ったときにはUEとeNB間の無線を運ばれるPDUという意味になる模様

 

ns3コード解析

SpectrumModel

vector(動的配列)でチャンネル情報の配列を渡すと、Band（構造体的なクラス）を個数分Vectorでメンバ変数に保持する。

予想

src/lte/test/lte-test-frequency-reuse.ccがベースになる。この中でクラスとして利用されているLteSpectrumPhyというのがあり、lte-spectrum-phy.ccがある。
lte-spectrum-phy.cc中にStartRXがあり、ここで計算処理を入れられそう。なので、lte-spectrum-phyとlte-ste-frequency-reuseをベースとして、書く。

また、RATCHはそのままで同期まではするが、UEからの送信Scheduringをしないので、MACを確率するために何処かの何かを継承したクラス中でOverrideして無効化してやる必要がある。

StartRxの中をよく見ると、受信のチャンネル等セットアップしかなかった。StartRxData中にm_pakcetBurstというのがある。これの個数で判別して落としたらいいんじゃ無いか？

lte-simple-spectrum-phy.ccを拡張する案

以下のコメント部分のように拡張できそう。

lte-simple-spectrum-phy.ccPtr<LteSpectrumSignalParametersDataFrame> lteDataRxParams = DynamicCast<LteSpectrumSignalParametersDataFrame> (spectrumRxParams);
  if (lteDataRxParams != 0)
    {

      //call StartRxData                                                                                                                                                     // m_interferenceData->AddSignal (rxPsd, duration);
      // StartRxData (lteDataRxParams);
      // //
      //if(lteDataRxParams->packetBurst){ //network/utils/packet-burst.h packet is stored in std::list                                                                       //  if(lteDataRxParams->packetBurst->GetNPackets > 10){
      //  discard overflow data
      //  }                                                                                                                                                                  //}

lteDataRxParamsには電波から来る複数個のpacketがpacketBurstに詰まっているので、これを個数調べてdeleteしたらいいんじゃないだろうか？listなので、適当に消せそう。

ENB受信時

lte-enb-phy.cc 430 LteEnbPhy::PhyPduReceived (Ptr p)

• m_enbPhySapUser->ReceivePhyPdu (p);
  と呼ばれているので実体を探す。

lte-enb-phy-sap.hclass LteEnbPhySapUser

{
public:
  virtual ~LteEnbPhySapUser ();

  /**
   * Called by the Phy to notify the MAC of the reception of a new PHY-PDU
   * \param p
   */
  virtual void ReceivePhyPdu (Ptr<Packet> p) = 0;

Virtualなので、どこかでOverrideされている。

lte-enb-mac.ccclass EnbMacMemberLteEnbPhySapUser : public LteEnbPhySapUser

{
public:
  EnbMacMemberLteEnbPhySapUser (LteEnbMac* mac);

  // inherited from LteEnbPhySapUser
  virtual void ReceivePhyPdu (Ptr<Packet> p);
　　：
    で
　　：
void EnbMacMemberLteEnbPhySapUser::ReceivePhyPdu (Ptr<Packet> p){
  m_mac->DoReceivePhyPdu (p);
}
　　：
　　で
　　：
void LteEnbMac::DoReceivePhyPdu (Ptr<Packet> p)
{
　　：

　　いろいろBerereTagを取り出してLCIDやRantiからLteMacSapUser*をmapで取り出すようになっている。
      (*lcidIt).second->ReceivePdu (p);　//LCID :Logical Channel ID
}

という感じで、

ENBが送信するとき

そもそもlte-enbと書いてあるのでeNB側のコードかと思ったが、実はUEのコードもある？？
lte-enb-mac.cc 449 LteEnbMac::DoSubframeIndication (uint32_t frameNo, uint32_t subframeNo)
ここで、ダウンリンクとアップリンクのCQI送信と、BSR送信をやっている
1．ダウンリンク
1.1. 受信したCQIがあったら、DL-CQIをスケジューラーに送る
1.2. 受信したRachPreableがあったら受信してスケジューラに通知する
1.3. これらの処理が終わっていたら、ダウンリンク転送の機会を得たことになる
1.4. 最後のTTIから集まったDL HARQフィードバックを転送する
1.5. m_schedSapProvider->SchedDlTriggerReq (dlparams);
2.アップリンク
2.1. UL-CQIをスケジューラーに送る
2.2. BSRレポートをスケジューラーに送る
2.3. これらの処理が終わっていたら、アップリンク転送の機会を得たことになる
2.4. 最後のTTIから集まったDL HARQフィードバックを転送する
2.5. m_schedSapProvider->SchedUlTriggerReq (ulparams);

UEが送信するとき

lte-ue-mac.cc　775
LteUeMac::SendReportBufferStatus (void)　314