本文经授权转自公众号“网优雇佣军”（ID：hr_opt）
据可靠情报，在前几天于意大利举行的3GPP会议上，3GPP扔出重磅炸弹：R15 Late Drop冻结时间推迟3个月。该计划推迟或将影响后续的R16版本冻结时间，也将可能导致推迟后续5G服务推出时间。
3GPP原计划在2018年12月冻结R15 Late Drop版本，并于2019年3月完成含有完整ASN.1 代码的标准版本，但本次会议决定，将R15 Late Drop版本的冻结时间推迟到2019年3月，ASN.1完成时间顺延至2019年6月。
R15为5G第一阶段标准，R16为5G第二阶段标准，该推迟计划可能将影响后续的R16版本冻结时间。原计划R16将于2019年12月冻结，而此次重新修改时间表后，R16估计将推迟于2020年3月冻结，并在2020年6月完成ASN.1冻结。
这到底是什么情况？
众所周知，2017年12月，3GPP完成了R15 NR NSA（非独立组网）标准；2018年6月14日，世界杯前夕，3GPP发布了R15 NR SA（独立组网）标准。
但是，事实上3GPP R15标准并未完全结束。
因为R15有三个版本：R15 NR NSA、R15 NR SA和 R15 late drop——没错，一个Release有三个版本，从来没有过。
这大概是因为2017年3GPP加速了标准制定速度，将原计划于2018年6月完成5G NR NSA标准提前到2017年12月完成，以满足部分运营商的先发需求，所以将5G第一阶段标准R15分成了三个版本分步走。
在2017年12月完成R15 NR NSA版本，2018年6月完成了R15 NR SA版本后，其实还剩下一个R15 late drop未完成。
那么，R15 NR NSA、R15 NR SA和R15 late drop到底有啥区别？剩下的R15 late drop包含了些什么内容呢？
这要从5G部署选项说起。
从3G演进到4G时，我们称之为”整体演进“，即无线接入网和核心网整体打包从3G演进到4G。但到了5G时代，就不一样了。
4G向5G演进时，无线接入网和核心网被拆开了，并且5G无线接入网（NR）、5G核心网、4G核心网和4G无线接入网（LTE）混合搭配，组成了多种网络部署选项的演进路线。
这些选项主要包括（如下图）：
-
选项2：独立组网（SA）模式，引入5G核心网，仅5G基站连接5G核心网。
-
选项3：非独立组网（NSA）模式，连接4G核心网，4G基站为主站，5G基站为辅站。
-
选项4：非独立组网（NSA）模式，引入5G核心网，5G基站为主站，4G基站为辅站。
-
选项5：独立组网（SA）模式，引入5G核心网，但仅4G基站连接到5G核心网。
-
选项7：非独立组网（NSA）模式，引入5G核心网，4G基站为主站，5G基站为辅站。
如上表可知，所谓非独立组网就是LTE与NR新无线的双连接，由于在具体实现上有差别，因此包含了三种构架：EN-DC（选项3）、NE-DC（选项4）和NGEN-DC（选项7）构架。
DC代表Dual Connectivity，即双连接；E代表E-UTRA，即4G无线接入网；N代表NR，即5G新无线；NG代表下一代核心网，即5G核心网。
EN-DC就是指4G无线接入网与5G NR的双连接，NE-DC指5G NR与4G无线接入网的双连接，而NGEN-DC指在5G核心网下的4G无线接入网与5G NR的双连接。
3GPP在2017年12月完成的R15 NR NSA（非独立组网）标准，就是选项3。而在6月14日完成的R15 NR SA（独立组网）标准，就是选项2。
至于剩下的选项4和选项7，将在R15 late drop版本里完成，原计划完成时间为2018年12月，而本次3GPP将完成时间推迟到了2019年3月。
R15 late drop主要包含的内容是：选项4（即NE-DC 构架）与选项7（即NGEN-DC构架）两种架构，以及NR-NR双连接（synchronous case）。
NR-NR双连接是什么呢？由于有些运营商计划采用低频段（比如700/800/900MHz频段）来建设5G网络的覆盖层，再用高频段（比如毫米波频段）来补充网络容量，但由于低和高频段的无线传播特性相差太大，共站实现载波聚合技术有些不实际，因此提出了NR-NR双连接技术。
为什么3GPP要推迟5G标准？
据说是为了预留更多的时间确保3GPP各种工作组之间充分协调，以及保证网络与终端、芯片之间更完善的兼容性等。
本次推迟标准完成时间，大多数代表都表示支持。前期因为标准制定加速，RAN工作组挑灯夜战赶进度，经常在晚上10点后还无法休息，实在是太累了。
微信公众号
随着Manus的出圈也让MCP(Model Context Protocol，模型上下文协议) 重新引起了大家的重视，说起MCP就不得不提另一个技术概念Function Call（函数调用），上一篇文章主要针对MCP进行全面的讲解，今天针对Function Call（函数调用）和MCP（Model Context Protocol，模型上下文协议)，分别从功能、定位、技术实现、适用场景等多个维度进行剖析，让大家能更好的理解和使用。
一、功能定位上区别
MCP Server
MCP Server（Model Context Protocol Server）是一种基于标准化协议的服务端程序，主要为大语言模型（LLM）提供外部数据和能力支持。例如，Fetch MCP Server可以抓取网页内容，Google Drive MCP Server可以读取文件。它的核心定位是“被动服务”，仅响应调用请求，不参与决策或推理。
MCP Server就像一个工具箱，里面装满了各种工具（如信息抓取、数据库查询、天气查询），但它不会主动使用这些工具，而是等待别人来挑选。MCP Server的功能相对单一，专注于提供数据和工具接口。例如，它可以抓取网页、读取文件或调用API，但不具备推理能力
优势：模块化设计，便于独立开发和扩展。
局限性：只能被动响应，无法主动解决问题。
Function Call
Function Call是指大模型直接调用预定义函数的能力，允许模型生成请求参数并整合结果。例如，模型可以通过Function Call查询天气或执行简单的数学计算。它的本质是“代码级工具”，通常与模型绑定部署。
Function Call就像一把瑞士军刀，虽然小巧但功能多样，可以直接嵌入模型中完成轻量级任务。适合处理简单、低延迟的任务，例如实时翻译、情感分析等。它与模型紧密集成，能够在推理过程中快速调用。
优势：高效便捷，无需额外通信开销。
局限性：受模型运行时资源限制，无法执行耗时任务。
二、交互方式
MCP Server
MCP Server采用被动服务模式，仅在接收到请求时返回数据。例如，当模型需要抓取网页内容时，会通过HTTP/SSE协议发送请求，MCP Server获取数据后返回。
Function Call
Function Call由模型运行时环境直接执行，开发者需预先定义函数并将其打包到模型服务中。这种方式适用于高频轻量任务。
三、技术实现
MCP工作流
Funtion Call 工作流
技术特性
四、应用场景
**MCP Server **
-
需要多步骤协作和上下文维护的场景
- 机票预订全流程：拆解为“意图解析→航班查询→用户选择→支付确认”，通过 MCP 协调各步骤的上下文传递
- 企业级智能客服:实现“问题分类→知识库检索→工单生成→反馈跟踪”的闭环流程
-
需统一通信协议和数据结构的需求
- 强制模型输出 JSON/XML 格式数据，与 ERP 系统对接
- 规范金融交易场景的订单字段结构和验证规则（如金额、账户校验）
-
多工具并行或串联调用的场景
- 智能家居控制：通过 MCP 协调“语音识别→设备控制→状态反馈”的跨系统协
- 作企业数据分析：同时调度本地数据库、云存储和可视化工具生成报告
**Function Call **
-
通过预定义函数直接触发外部服务
- 实时数据查询：调用 get_weather()获取天气数据、get_stock_price() 查询股价等。
- 简单指令执行：用户说“发邮件给客户”时，直接触发 send_email（） 函数。
- 厂商专属功能：例如 OpenAI 的 GPT-4 调用 DALL·E 生成图片。
-
对上下文管理要求较低的场景
- 单次问答中调用计算器工具完成数学运算。
- 通过 search_flights 接口直接返回航班列表。
-
依赖特定厂商接口的场景
- 基于 OpenAI Function Call 开发封闭生态工具。
- 快速实现模型与私有 API 的对接（无需标准化协议）。
总结
MCP Server和Function Calling代表着两种不同的AI交互范式,它们各有优势,适用于不同的应用场景.对于开发者而言,关键是要理解这两种方案的本质区别，根据任务复杂度、团队协作需求和安全隔离性综合选择。通过合理搭配，可以构建出高效、灵活的AI系统，释放大模型的最大潜力。
评论记录：
回复评论：