关于5G到4G切换流程中的create session request问题

varsarch

通常在4G的PDN会话建立，或者带SGW重选的TAU等流程中，当SGW收到了MME的create session request消息时，都会根据PGW-C的地址信息，通过create session request或modify bearer request消息与PGW进行S5-U的承载协商的。但是在5到4的切换流程中，MME通过N26口也获取到了相关映射EPS承载所对应的SMF/PGW-C和UPF/PGW-U的控制面和用户面信息，也一样通过create session request消息发给了新选择的SGW，但是SGW就没有像相关4G流程那样再与PGW进行交互协商，而是直接就回复了create session response给MME。请问这是在create session request消息中哪里标识控制的？SGW是怎样知道这是一个需要建立间接转发通道的切换流才这样处理的吗？谢谢！

admin

说下个人理解，供参考。
先拆分成两个问题。
Q1:5到4的切换的流程中SGW收到create session request后，为啥没像EPC初始附着时那样去找PGW，而是直接回了Create session response。
-- 个人理解：这个应该是23502的4.11.1.2.1 5GS to EPS handover using N26 interface的第4（create session request）和第5步（create session response）。实际上这个不是5G新发明的，而是复用了4G的S1 HO也是这样的。规范原文是：4-5. Step 4 and 4a respectively in clause 5.5.1.2.2 (S1-based handover, normal) in TS 23.401。顺腾摸瓜找到23401的5.5.1.2.2的4和4a步，发现也是这样的，SGW没去找PGW，直接回了response。
个人理解就是SGW为什么要找PGW？主要是做两件事。
1是请求PGW切换下行用户面通道到4G，但现在还是准备阶段，UE都还在5G。这个用途肯定不是。
2是请求PGW建立间接转发隧道，用于切换过程中下行数据的临时转发。这个步骤有，是在后面(等MME收到基站的HO ack之后）。这里我想有两个原因：
- 首先按照切换准备阶段的惯例，需要多个接口预留资源，按惯例，一般是先请求空口预留，把最稀缺最难搞的空口资源预留成功，然后再去做核心网这侧的预留或用户面隧道建立。也就是先难后易。顺序不能反。免得把核心网先预留了，待会空口说不行没资源，那就白做了。
- 再者就是这个是5到4的切换，而且是准备阶段，控制面的锚点应该是AMF和SMF（不要说和PGW-C合设，从role看是SMF的职责）。因此SGW直接去找PGW-C去建间接转发隧道也是不合清理的。因此，在后面的步骤可以看到，间接转发隧道的建立，也是SGW给MME回了response（而不是自己直接去找PGW建立），MME找AMF，AMF再去找SMF，SMF找到合设的PGW-C来做更新。这样可能也更合逻辑一些。
只有在切换完成阶段，UE已经到4G了，SGW才给PGW发了modify bearer request，请求PGW将下行用户面通道切到4G。

Q2: SGW怎么知道这是不同的流程，然后决定要不要去找PGW？
A2：查了下29274，create session request里有两个参数可以用于区分流程，一个是PAA参数，如果是EPC初始附着，代表还没有分配UE IP，取值为0.0.0.0，如果是切换，UE IP已经分配了，取值为UE的IP。另外还有一个handover inditcation flag。
特意找了两个包，供您参考对照。
EPC附着流程里的Create session request（S11口）

GPRS Tunneling Protocol V2
    Flags: 0x48
    Message Type: Create Session Request (32)
    Message Length: 212
    Tunnel Endpoint Identifier: 0x00000000 (0)
    Sequence Number: 0x00034f00 (216832)
    Spare: 0
    International Mobile Subscriber Identity (IMSI) : 4600X666001001005
    MSISDN : 8613X66668888
    User Location Info (ULI) : TAI ECGI
    Serving Network : MCC 460 China, MNC XX
    RAT Type : EUTRAN (6)
    Indication :
    Fully Qualified Tunnel Endpoint Identifier (F-TEID) : S11 MME GTP-C interface, TEID/GRE Key: 0x171040af, IPv4 1.1.1.1
    Fully Qualified Tunnel Endpoint Identifier (F-TEID) : S5/S8 PGW GTP-C interface, TEID/GRE Key: 0x00000000, IPv4 2.2.2.2
    Access Point Name (APN) : internet.mncxxx.mcc460.gprs
    Selection Mode : MS or network provided APN, subscribed verified
    PDN Type : IPv4
    PDN Address Allocation (PAA) : IPv4 0.0.0.0
    APN Restriction : No Existing Contexts or Restriction (0)
    Aggregate Maximum Bit Rate (AMBR) :
    Recovery (Restart Counter) : 137
    Bearer Context  

5到4切换流程里的Create Session Request（S11）
GPRS Tunneling Protocol V2
    Flags: 0x48
    Message Type: Create Session Request (32)
    Message Length: 175
    Tunnel Endpoint Identifier: 0x00000000 (0)
    Sequence Number: 0x0017c7e1 (1558497)
    Spare: 0
    International Mobile Subscriber Identity (IMSI) : 4600X666001001005
    Mobile Equipment Identity (MEI) : 8613X66668888
    Serving Network : MCC 460 China, MNC XX
    RAT Type : EUTRAN (6)
    Fully Qualified Tunnel Endpoint Identifier (F-TEID) : S11 MME GTP-C interface, TEID/GRE Key: 0x5cb80007, IPv4 IPv4 1.1.1.1
    Fully Qualified Tunnel Endpoint Identifier (F-TEID) : S5/S8 PGW GTP-C interface, TEID/GRE Key: 0x1010ae61, IPv4 2.2.2.2
    Access Point Name (APN) : internet.mncxxx.mcc460.gprs
    PDN Address Allocation (PAA) : IPv4 10.1.1.1
    APN Restriction : No Existing Contexts or Restriction (0)
    EPS Bearer ID (EBI) : 5
    Bearer Context  

51xuetongxin_ty

admin 发表于 2022-8-14 15:12
说下个人理解，供参考。
先拆分成两个问题。
Q1:5到4的切换的流程中SGW收到create session request后，为 ...

关于5G切换到4G的特征，如果采用Create Session Request中的PAA字段是否为空，可能会没法区分是5G切换到4G，还是2/3G切换到4G的动作，还有handover inditcation flag字段3gpp标准解释不能唯一确定是5G切换到4G