> The generated `<data_model>.pb.go` files will contain all the protocol buffer code to populate, serialize, and retrieve request and response message types defined in the `models` folder.
> The `bwm_service_grpc.pb.go` will contain the stubs for the methods defined in the `bwm_service.proto` file.
### Ruby
1. Install gRPC Ruby Plugin and required tools
```sh
$ gem install grpc
$ sudo apt install ruby-grpc-tools
```
2. Generate code
```sh
$ mkdir ruby-stubs
```
Run the following command to create Ruby modules for all the data models defined in the proto files.
Run the following command to generate `bwm_service_pb.rb` and `bwm_service_services_pb.rb` files, containing stub and service classes for the endpoints and methods defined in BWM service.
// The direction of the requested BW allocation: 00 = Downlink (towards the UE) 01 = Uplink (towards the application/session) 10 = Symmetrical
stringallocationDirection=3;
// Application instance identifier
stringappInsId=4;
// Size of requested fixed BW allocation in [bps]
stringfixedAllocation=5;
// Indicates the allocation priority when dealing with several applications or sessions in parallel. Values are not defined in the present document
enumFixedBWPriorityEnum{
SEE_DESCRIPTION=0;
}
FixedBWPriorityEnumfixedBWPriority=6;
// Numeric value (0 - 255) corresponding to specific type of consumer as following: 0 = APPLICATION_SPECIFIC_BW_ALLOCATION 1 = SESSION_SPECIFIC_BW_ALLOCATION
enumRequestTypeEnum{
_0=0;
_1=1;
}
RequestTypeEnumrequestType=7;
// Session filtering criteria, applicable when requestType is set as SESSION_SPECIFIC_BW_ALLOCATION. Any filtering criteria shall define a single session only. In case multiple sessions match sessionFilter the request shall be rejected
// The direction of the requested BW allocation: 00 = Downlink (towards the UE) 01 = Uplink (towards the application/session) 10 = Symmetrical
stringallocationDirection=2;
// Application instance identifier
stringappInsId=3;
// Size of requested fixed BW allocation in [bps]
stringfixedAllocation=4;
// Indicates the allocation priority when dealing with several applications or sessions in parallel. Values are not defined in the present document
enumFixedBWPriorityEnum{
SEE_DESCRIPTION=0;
}
FixedBWPriorityEnumfixedBWPriority=5;
// Numeric value (0 - 255) corresponding to specific type of consumer as following: 0 = APPLICATION_SPECIFIC_BW_ALLOCATION 1 = SESSION_SPECIFIC_BW_ALLOCATION
enumRequestTypeEnum{
_0=0;
_1=1;
}
RequestTypeEnumrequestType=6;
// Session filtering criteria, applicable when requestType is set as SESSION_SPECIFIC_BW_ALLOCATION. Any filtering criteria shall define a single session only. In case multiple sessions match sessionFilter the request shall be rejected
The ETSI MEC ISG Bandwidth Management API described using OpenAPI.
The version of the OpenAPI document: 2.2.1
Generated by OpenAPI Generator: https://openapi-generator.tech
*/
syntax="proto3";
packagemec015;
messageBwInfoDeltasSessionFilter{
// Destination address identity of session. The string for an IPv4 address shall be formatted in the \"dotted decimal\" notation as defined in IETF RFC 1166 [10]. The string for an IPv6 address shall be formatted according to clause 4 of IETF RFC 5952 [11], with in CIDR notation [12] used to provide the routing prefix
stringdstAddress=1;
// Destination port identity of session
repeatedstringdstPort=2;
// Protocol number
stringprotocol=3;
// Source address identity of session. The string for an IPv4 address shall be formatted in the \"dotted decimal\" notation as defined in IETF RFC 1166 [10]. The string for an IPv6 address shall be formatted according to clause 4 of IETF RFC 5952 [11], with in CIDR notation [12] used to provide the routing prefix
The ETSI MEC ISG Bandwidth Management API described using OpenAPI.
The version of the OpenAPI document: 2.2.1
Generated by OpenAPI Generator: https://openapi-generator.tech
*/
syntax="proto3";
packagemec015;
messageBwInfoSessionFilter{
// Destination address identity of session. The string for an IPv4 address shall be formatted in the \"dotted decimal\" notation as defined in IETF RFC 1166 [10]. The string for an IPv6 address shall be formatted according to clause 4 of IETF RFC 5952 [11], with in CIDR notation [12] used to provide the routing prefix
stringdstAddress=1;
// Destination port identity of session
repeatedstringdstPort=2;
// Protocol number
stringprotocol=3;
// Source address identity of session. The string for an IPv4 address shall be formatted in the \"dotted decimal\" notation as defined in IETF RFC 1166 [10]. The string for an IPv6 address shall be formatted according to clause 4 of IETF RFC 5952 [11], with in CIDR notation [12] used to provide the routing prefix
// A MEC application instance may use multiple app_instance_ids as an input parameter to query the bandwidth allocation of a list of MEC application instances. app_instance_id corresponds to appInsId defined in table 7.2.2-1. See note.
repeatedstringappInstanceId=1;
// A MEC application instance may use multiple app_names as an input parameter to query the bandwidth allocation of a list of MEC application instances. app_name corresponds to appName defined in table 7.2.2-1. See note.
repeatedstringappName=2;
// A MEC application instance may use session_id as an input parameter to query the bandwidth allocation of a list of sessions. session_id corresponds to allocationId defined in table 7.2.2-1. See note.
repeatedstringsessionId=3;
}
messageBandwidthAllocationListGETResponse{
repeatedBwInfodata=1;
}
messageBandwidthAllocationPATCHRequest{
// Represents a bandwidth allocation instance
stringallocationId=1;
// Description of the changes to instruct the server how to modify the resource representation.
BwInfoDeltasbwInfoDeltas=2;
}
messageBandwidthAllocationPOSTRequest{
// Entity body in the request contains BwInfo to be created.
BwInfobwInfo=1;
}
messageBandwidthAllocationPUTRequest{
// Represents a bandwidth allocation instance
stringallocationId=1;
// BwInfo with updated information is included as entity body of the request.
*[Navigate the Bandwidth Management API in the browser](https://redocly.github.io/redoc/?url=https://forge.etsi.org/rep/mec/gs015-bandwith-mgmt-api/-/raw/v2.1.1-OAS3.1/BwManagementApi.yaml)
*[Navigate the Bandwidth Management API in the browser](https://redocly.github.io/redoc/?url=https://forge.etsi.org/rep/mec/gs015-bandwith-mgmt-api/-/raw/v2.2.1-OAS3.1/BwManagementApi.yaml)
*[Navigate the Traffic Steering API in the browser](https://redocly.github.io/redoc/?url=https://forge.etsi.org/rep/mec/gs015-bandwith-mgmt-api/-/raw/v2.1.1-OAS3.1/TrafficSteeringApi.yaml)
*[Navigate the Traffic Steering API in the browser](https://redocly.github.io/redoc/?url=https://forge.etsi.org/rep/mec/gs015-bandwith-mgmt-api/-/raw/v2.2.1-OAS3.1/TrafficSteeringApi.yaml)
The present document focuses on the Multi-access Traffic Steering multi-access edge service. It describes the related application policy information including authorization and access control, information flows, required information and service aggregation patterns. The present document specifies the necessary API with the data model and data format.
## Overview
These files were generated by the [OpenAPI Generator](https://openapi-generator.tech) project.
> The generated `<data_model>.pb.go` files will contain all the protocol buffer code to populate, serialize, and retrieve request and response message types defined in the `models` folder.
> The `mts_service_grpc.pb.go` will contain the stubs for the methods defined in the `mts_service.proto` file.
### Ruby
1. Install gRPC Ruby Plugin and required tools
```sh
$ gem install grpc
$ sudo apt install ruby-grpc-tools
```
2. Generate code
```sh
$ mkdir ruby-stubs
```
Run the following command to create Ruby modules for all the data models defined in the proto files.
Run the following command to generate `mts_service_pb.rb` and `mts_service_services_pb.rb` files, containing stub and service classes for the endpoints and methods defined in MTS service.
ETSI GS MEC 015 Multi-access Traffic Steering APIs
The present document focuses on the Multi-access Traffic Steering multi-access edge service. It describes the related application policy information including authorization and access control, information flows, required information and service aggregation patterns. The present document specifies the necessary API with the data model and data format.
The version of the OpenAPI document: 2.2.1
Generated by OpenAPI Generator: https://openapi-generator.tech
// Numeric value corresponding to a specific MTS operation supported by the TMS 0 = low cost, i.e. using the unmetered access network connection whenever it is available 1 = low latency, i.e. using the access network connection with lower latency 2 = high throughput, i.e. using the access network connection with higher throughput, or/and multiple access network connection simultaneously if supported 3 = redundancy, i.e. sending duplicated (redundancy) packets over multiple access network connections for highreliability and low-latency applications 4 = QoS, i.e. performing MTS based on the specific QoS requirements from the app
ETSI GS MEC 015 Multi-access Traffic Steering APIs
The present document focuses on the Multi-access Traffic Steering multi-access edge service. It describes the related application policy information including authorization and access control, information flows, required information and service aggregation patterns. The present document specifies the necessary API with the data model and data format.
The version of the OpenAPI document: 2.2.1
Generated by OpenAPI Generator: https://openapi-generator.tech
*/
syntax="proto3";
packagemec015;
messageMtsCapabilityInfoMtsAccessInfo{
// Unique identifier for the access network connection
int32accessId=1;
// Numeric value (0-255) corresponding to specific type of access network as following: 0 = Unknown 1 = Any IEEE802.11-based WLAN technology 2 = Any 3GPP-based Cellular technology 3 = Any Fixed Access 11 = IEEE802.11 a/b/g WLAN 12 = IEEE 802.11 a/b/g/n WLAN 13 = IEEE 802.11 a/b/g/n/ac WLAN 14 = IEEE 802.11 a/b/g/n/ac/ax WLAN (Wi-Fi 6) 15 = IEEE 802.11 b/g/n WLAN 31 = 3GPP GERAN/UTRA (2G/3G) 32 = 3GPP E-UTRA (4G/LTE) 33 = 3GPP NR (5G)
int32accessType=2;
// Numeric value (0-255) corresponding to the following: 0: the connection is not metered (see note) 1: the connection is metered 2: unknown
ETSI GS MEC 015 Multi-access Traffic Steering APIs
The present document focuses on the Multi-access Traffic Steering multi-access edge service. It describes the related application policy information including authorization and access control, information flows, required information and service aggregation patterns. The present document specifies the necessary API with the data model and data format.
The version of the OpenAPI document: 2.2.1
Generated by OpenAPI Generator: https://openapi-generator.tech
// Traffic flow filtering criteria, applicable only if when requestType is set as FLOW_SPECIFIC_MTS_SESSION. Any filtering criteria shall define a single session only. In case multiple sessions match flowFilter the request shall be rejected. If the flowFilter field is included, at least one of its subfields shall be included. Any flowFilter subfield that is not included shall be ignored in traffic flow filtering
repeatedMtsSessionInfoFlowFilterflowFilter=4;
// Numeric value (0 - 255) corresponding to a specific MTS mode of the MTS session: 0 = low cost, i.e. using the unmetered access network connection whenever it is available 1 = low latency, i.e. using the access network connection with lower latency 2 = high throughput, i.e. using the access network connection with higher throughput, or multiple access network connection simultaneously 3 = redundancy, i.e. sending duplicated (redundancy) packets over multiple access network connections for high-reliability and low-latency applications 4 = QoS, i.e. performing MTS based on the QoS requirement (qosD)
int32mtsMode=5;
QosDqosD=6;
// Numeric value (0 - 255) corresponding to specific type of consumer as following: 0 = APPLICATION_SPECIFIC_MTS_SESSION 1 = FLOW_SPECIFIC_MTS_SESSION
enumRequestTypeEnum{
_0=0;
_1=1;
}
RequestTypeEnumrequestType=7;
TimeStamp1timeStamp=8;
// The direction of the requested MTS session: 00 = Downlink (towards the UE) 01 = Uplink (towards the application/session) 10 = Symmetrical (see note)