Hi All,
Please suggest which MO can be checked to see S1-User plane definition in Ericsson.
I could only see S1-C(Termpointtomme) in all the nodes I have verified.
On the eNodeB there is no S1-U peer MO. TermPointToMme exists because S1-C has a static SCTP association per MME, but S1-U has no equivalent term point, because S1-U bearers are set up per UE over GTP-U at call setup and the SGW endpoint comes in the S1AP signalling, not from a configured MO.
What defines S1-U on the node is the local GTP-U termination address in the transport branch under EnodeBFunction, not a peer MO. Get the node type and release and check the exact MO and attribute holding that S1-U GTP-U endpoint.
Okay noted. So should I have to give get enodefunction=
Not EnodeBFunction directly, that holds the S1 function but not the user-plane IP. The S1-U GTP-U endpoint lives in the transport branch, and the exact MO depends on release. Two ways to find it fast on the node.
Reverse-map from the address. Run
st Sctp lt all get . gtpu
The get . gtpu (dot-match on all MOs containing gtpu) will return the Gtpu MO and the reference to the IP address it uses for S1-U. That is the quickest, it lists the user-plane endpoint wherever it sits in your release.
Then follow the reference. The Gtpu MO points to an AddressIPv4 (or the endpoint reference MO in newer releases) under the transport configuration, and that address is your S1-U termination.
Run get . gtpu first and paste the output. Tell me the node type and release with it, and I will name the exact MO and attribute so you can pull it in one command next time.
Node type is BB6630 and release 26Q2
MO Attribute Value
ENodeBFunction=1 gtpuErrorIndicationDscp 40
ENodeBFunction=1 s1GtpuEchoDscp 14
ENodeBFunction=1 s1GtpuEchoEnable 0 (DISABLED)
ENodeBFunction=1 s1GtpuEchoFailureAction 0 (NONE)
ENodeBFunction=1 x2GtpuEchoDscp 14
ENodeBFunction=1 x2GtpuEchoEnable 0 (DISABLED)
Those are just GTP-U echo/DSCP policy attributes on EnodeBFunction, not the S1-U endpoint, so that dot-match landed on the wrong MO. On BB6630 at 26Q2 the S1-U user-plane termination lives in the EndpointResource / GTP-U branch under Transport, not on EnodeBFunction.
Pull it with these on the node:
get . EndpointResource get . GtpuEndpt get . Sctp
The S1-U GTP-U endpoint on this release is the GtpuEndpt (or the EndpointResource that references it), and it points to an AddressIPv4 or an InterfaceIPv4 that is your S1-U user-plane IP. That address plus its reference chain is the S1-U definition you are looking for.
Run get . EndpointResource and paste what comes back. That MO tree will show the GTP-U endpoint and the IP it binds to, and from there I will name the exact attribute holding the S1-U address for BB6630 26Q2 so you can pull it in one line.
There are no output for get . EndpointResource. We have output for get.sctp
=================================================================================================================
MO Attribute Value
ENodeBFunction=1 sctpEndcX2Ref SctpEndpoint=eNB
ENodeBFunction=1 sctpRef SctpEndpoint=1
ENodeBFunction=1 sctpX2Ref SctpEndpoint=eNB
Sctp=General sctpId General
SctpEndpoint=1 dtlsSctpSecurityMode 0 (DISABLED)
SctpEndpoint=1 sctpEndpointId 1
SctpEndpoint=1 sctpProfile SctpProfile=1
SctpEndpoint=1,SctpAssociation=36412-172.29.45.30 pmtudSctpPduSize s[4] = 2a01:8f1:e4f8:519::1-2a01:8f0:ff0e:5100::8,INCONCLUSIVE 2a01:8f1:e4f8:519::1-2a01:8f0:ff0e:5100::9,INCONCLUSIVE 172.31.224.168-172.29.45.30,INCONCLUSIVE 172.31.224.168-172.29.45.31,INCONCLUSIVE
SctpEndpoint=1,SctpAssociation=36412-172.29.45.30 sctpAssociationId 36412-172.29.45.30
SctpEndpoint=eNB dtlsSctpSecurityMode 0 (DISABLED)
SctpEndpoint=eNB sctpEndpointId eNB
SctpEndpoint=eNB sctpProfile SctpProfile=2
SctpProfile=1 maxSctpPduSize 1380
SctpProfile=1 sctpProfileId 1
SctpProfile=2 maxSctpPduSize 1460
SctpProfile=2 sctpProfileId 2
SctpProfile=3 maxSctpPduSize 0
SctpProfile=3 sctpProfileId 3
That SCTP output is the control plane (S1-C: SctpAssociation on 36412 to the MME, plus the X2 endpoint), which confirms your point that only the control side shows as MOs. It does not carry the S1-U user-plane IP, and the empty EndpointResource result tells us this node uses the older transport model, not the newer EndpointResource one.
On this node, S1-U is the GTP-U termination, and it is under the Transport branch as an AddressIPv4 referenced by the Ep/GTP-U configuration, not on EnodeBFunction. Since the modern MO returned nothing, read the transport IP model directly:
get . AddressIPv4 get . Gtpu
get . AddressIPv4 lists every configured transport IP with its MO, and one of them is the S1-U/GTP-U user-plane address. get . Gtpu returns the GTP-U MO that references which AddressIPv4 is used for the user plane. The address the Gtpu MO points to is your S1-U definition.
Run those two and paste the output. If AddressIPv4 also comes back empty, tell me and I will give the exact transport-IP MO for BB6630 26Q2, because it means the user-plane IP sits under a different transport MO name on your build and I will name it rather than guess.
Router=Alternative_OAM,InterfaceIPv4=Alternative_OAM,AddressIPv4=Alternative_OAM addressIPv4Id Alternative_OAM
Router=CUP_Inner,InterfaceIPv4=2,AddressIPv4=1 addressIPv4Id 1
Router=CUP_Outer,InterfaceIPv4=1,AddressIPv4=1 addressIPv4Id 1
Router=CUP_Outer,InterfaceIPv4=SYNC,AddressIPv4=1 addressIPv4Id 1
Router=OaM,InterfaceIPv4=1,AddressIPv4=1 addressIPv4Id 1
Total: 5 MOs
Now it’s clear — this node uses the CUP transport model (control/user-plane separation), so your S1-U user-plane IP is the address on the CUP_Inner router, and the OAM/SYNC ones are not it.
From your output, the S1-U/GTP-U user-plane address is here:
Router=CUP_Inner,InterfaceIPv4=2,AddressIPv4=1
CUP_Inner carries the inner user-plane traffic (S1-U and X2-U GTP-U), CUP_Outer is the outer/transport and SYNC IPs, and Router=OaM plus Alternative_OAM are management. So the user plane you were looking for lives under CUP_Inner, not under any S1 peer MO.
Confirm and read the actual IP with:
get Router=CUP_Inner,InterfaceIPv4=2,AddressIPv4=1 get . Gtpu
The first returns the address value on CUP_Inner, which is your S1-U termination IP. get . Gtpu shows the GTP-U MO and will reference back to that CUP_Inner address, closing the link between the user plane function and the IP. That reference is the S1-U user-plane definition on BB6630 26Q2.
OKay, but this address is enb innerip, so in this case innerip and userplane IP are same?
=================================================================================================================
13493 Transport=1,Router=CUP_Inner,InterfaceIPv4=2,AddressIPv4=1
=================================================================================================================
address 172.31.224.168/32
addressIPv4Id 1
configurationMode 0 (MANUAL)
dhcpClientIdentifier
dhcpClientIdentifierType 0 (AUTOMATIC)
primaryAddress true
reservedBy [3] =
>>> reservedBy = ENodeBFunction=1
>>> reservedBy = Transport=1,SctpEndpoint=1
>>> reservedBy = Transport=1,Router=CUP_Inner,TwampResponder=1
usedAddress 172.31.224.168/32
userLabel CUP-Inner
=================================================================================================================
Total: 1 MOs
get. gtpu output
=================================================================================================================
MO Attribute Value
=================================================================================================================
ENodeBFunction=1 gtpuErrorIndicationDscp 40
ENodeBFunction=1 s1GtpuEchoDscp 14
ENodeBFunction=1 s1GtpuEchoEnable 0 (DISABLED)
ENodeBFunction=1 s1GtpuEchoFailureAction 0 (NONE)
ENodeBFunction=1 x2GtpuEchoDscp 14
ENodeBFunction=1 x2GtpuEchoEnable 0 (DISABLED)
=================================================================================================================
Total: 1 MOsYes — on this node the CUP_Inner address is the S1-U user-plane IP. They are the same. Your own output proves it: the reservedBy list on that AddressIPv4 shows it is used by both ENodeBFunction=1 (the GTP-U user plane) and Transport=1,SctpEndpoint=1 (the SCTP control plane). So 172.31.224.168/32 is the single transport address carrying both S1-C and S1-U on this design.
That reservedBy line is the definitive answer to your original question. There is no separate S1-U peer MO or a distinct user-plane address to find. S1-U is defined by ENodeBFunction reserving the CUP_Inner AddressIPv4 as its GTP-U endpoint, and that reservation is the link you were looking for.
The get . gtpu output only shows the echo/DSCP policy because on BB6630 26Q2 the GTP-U function does not hold its own IP attribute. It inherits the endpoint from the reserved CUP_Inner address instead, which is exactly why the address appears under reservedBy = ENodeBFunction=1 rather than as a gtpu attribute.
So to confirm S1-U on any node of this build, the one-line check is: read the AddressIPv4 on CUP_Inner and look at reservedBy — if ENodeBFunction is listed, that address is the S1-U GTP-U termination. Here it is 172.31.224.168/32, shared with S1-C.
How did we know enodebfunction=1 means gtp-u user plane?
reservedBy = ENodeBFunction=1 only proves the eNodeB owns the address, not that it is user plane. It is the GTP-U endpoint by elimination: the SCTP reservation on the same IP is S1-C, TwampResponder is OAM/test, so the remaining ENodeBFunction reservation is S1-U/X2-U GTP-U.
Confirm directly instead of inferring:
get . EpS1U get . GtpuEndpt
Whichever returns an MO referencing Router=CUP_Inner,InterfaceIPv4=2,AddressIPv4=1 is the explicit S1-U endpoint binding. Paste it and it is proven, not inferred.