一句話重點
衛星訊號不是「從 A 傳到 B」這麼簡單，而是一條由終端、天線、衛星、地面站、網路與應用平台組成的服務鏈。
PM 為什麼需要知道
當客戶說「衛星網路很慢」、「資料沒有回來」、「設備連不上」時，問題可能發生在很多地方。新手 PM 如果只把問題想成「衛星訊號不好」，就很難協調工程、客服、營運與商務團隊。
PM 不一定要會設計 RF 鏈路，但要能把服務拆成幾段，並知道每一段可能造成什麼產品影響。
衛星通訊的基本路徑
一個典型衛星通訊鏈路可以拆成七段。
第一段是使用者設備或感測器。這可能是船上的終端、車隊追蹤器、偏鄉網路設備、手機、基地台回傳設備，或某種 IoT 感測器。產品體驗通常從這裡開始。
第二段是天線與 RF 前端。天線負責把電訊號轉成電磁波，也負責接收從衛星來的微弱訊號。天線增益、方向性、安裝角度、線材損耗、放大器與濾波器都會影響鏈路品質。
第三段是上行鏈路。上行是從地面傳到衛星。上行品質取決於發射功率、天線增益、頻段、天候、遮蔽、距離、干擾與衛星接收能力。
第四段是衛星有效載荷。衛星收到訊號後，可能只是轉頻與放大，也可能進行數位處理、波束切換、路由、再生式處理或星間鏈路轉送。不同衛星架構會讓服務能力差很多。
第五段是下行鏈路。下行是從衛星傳到地面站或另一個終端。它同樣受到功率、天線、頻段、路徑損耗、天氣與干擾影響。
第六段是地面站或閘道器。地面站把衛星訊號接回地面網路，可能連到資料中心、核心網路、Internet、私有網路或雲端平台。
第七段是平台與應用。客戶最後看到的是網站、API、儀表板、告警、資料庫或企業系統。即使衛星鏈路正常，平台處理慢、API 失敗或資料格式錯誤，也會讓客戶覺得服務失敗。
上行與下行不是同一件事
PM 要特別注意，上行與下行的限制可能不同。
例如一個 IoT 終端可能只需要每天上傳幾筆感測資料，上行很小；但如果產品要下發韌體更新，下行需求就會突然變大。又例如衛星寬頻服務可能下行頻寬很高，但上行頻寬較低，這會影響視訊會議、雲端備份、遠端監控等應用。
因此，需求不能只寫「支援 10 Mbps」。PM 要問清楚：
- 上行多少？
- 下行多少？
- 平均多少？
- 峰值多少？
- 持續多久？
- 在什麼環境下成立？
地面站是衛星服務的關鍵
很多人以為衛星服務只靠太空端，但地面站常常是產品成敗的關鍵。
地面站的位置會影響衛星可見時間、服務區域、延遲與法規。地面站數量會影響可用性與備援能力。地面站到資料中心或客戶網路的連線，會影響整體延遲與吞吐。
對 PM 來說，地面站不是後台工程細節，而是服務品質的一部分。如果產品要賣給跨國客戶，還要考慮資料是否能跨境、是否需要本地落地、是否有監管限制。
波束與容量
衛星不是把訊號平均灑到整個地球。許多通訊衛星會使用波束，把資源集中在特定區域。波束可以提升容量與頻譜效率，但也讓產品規劃更複雜。
同一個國家內，不同地區可能落在不同波束。某些區域可能有覆蓋但容量不足。某些移動場景可能跨波束移動，需要處理切換。
PM 要記住一個重要句子：有覆蓋不等於有容量，有容量不等於使用者體驗穩定。
常見誤解
誤解一：訊號傳得到就代表產品可用。
訊號可達只是物理層的一部分。客戶在意的是資料是否完整、延遲是否可接受、服務是否穩定、平台是否可用。
誤解二：終端顯示連線就代表鏈路健康。
連線狀態可能只是註冊成功，不代表吞吐、延遲、封包遺失與應用服務都正常。PM 要要求更完整的狀態指標。
誤解三：衛星問題一定在太空。
問題可能在天線安裝、線材、電源、韌體、地面站、回程網路、核心網路、平台 API 或客戶端系統。
可以問工程師的問題
- 這個服務鏈路包含哪些節點？
- 每個節點有哪些監控指標？
- 客戶端看到斷線時，我們能追到哪一段出問題嗎？
- 上行與下行的容量限制是否不同？
- 地面站是否有備援？切換時間多長？
- 波束切換是否會造成短暫中斷？
- 平台層是否能區分「衛星鏈路失敗」和「應用處理失敗」？
小結
衛星訊號的產品價值，來自端到端服務鏈，而不是單一訊號強度。PM 要能從終端一路追到平台，知道每一段如何影響客戶體驗。
下一次遇到「連不上」或「速度慢」，不要只問「衛星訊號好不好」。更好的問題是：問題發生在哪一段？我們有沒有數據？使用者感受到的是什麼？這才是衛星 PM 開始變強的地方。
延伸閱讀
